karabouzouk... Δημοσ. 21 Μαΐου 2012 Δημοσ. 21 Μαΐου 2012 Καλησπέρα παιδιά..! Επειδή έχω φάει τα μυαλά μου με κάτι που μάλλον είναι απλό αν το έχει ξανακάνει κάποιος όποιος έχει ιδέα ας βοηθήσει..! Σε php.. $row = $statement->fetch() //εδώ στην μεταβλητή $row έχουμε μια εγγραφή από αυτές που επέστρεψε το ερώτημα από τη βάση μας $row[8] //είναι το πεδίο που περιέχει μια ημερομηνία από τη βάση τύπου DATE. Αυτό που θέλω να υπολογίσω είναι αν η διαφορά της ημερομηνίας που επιστρέφεται από τη βάση, σε σύγκριση με τη σημερινή ημερομηνία είναι μεγαλύτερη ας πούμε από 40 μέρες. Δοκίμασα μερικές λύσεις που βρήκα στο internet αλλά δεν μου δούλεψε κάποια... Έχετε κάποια λύση..? Ευχαριστώ πολύ!
computeras13 Δημοσ. 21 Μαΐου 2012 Δημοσ. 21 Μαΐου 2012 Υπάρχει κάποιος λόγος που θέλεις να το κάνεις αυτό μέσω php και όχι με την χρήση sql; Μπορείς να χρησιμοποιήσεις στο query σου την συνάρτηση now() και να φέρεις αντίστοιχα τις εγγραφές που ισχύει η συνθήκη σου ή το αντίθετο. Μπορείς βέβαια να το κάνεις να ενημερώνει μια custom boolean στήλη που θα φτιάχνεις εκείνη την στιγμή στο query αν θες απαραίτητα να παίρνεις την πληροφορία πίσω στον κώδικά σου.
karabouzouk... Δημοσ. 21 Μαΐου 2012 Μέλος Δημοσ. 21 Μαΐου 2012 Υπάρχει κάποιος λόγος που θέλεις να το κάνεις αυτό μέσω php και όχι με την χρήση sql; Μπορείς να χρησιμοποιήσεις στο query σου την συνάρτηση now() και να φέρεις αντίστοιχα τις εγγραφές που ισχύει η συνθήκη σου ή το αντίθετο. Μπορείς βέβαια να το κάνεις να ενημερώνει μια custom boolean στήλη που θα φτιάχνεις εκείνη την στιγμή στο query αν θες απαραίτητα να παίρνεις την πληροφορία πίσω στον κώδικά σου. Είναι πολύ πιο δύσκολο να γίνει η σύγκριση μέσα στην php ή απλά πιστεύεις ότι δεν είναι σωστή τακτική..? Βασικά απλά έτσι όπως είναι ο κώδικας μου (έχω αρκετά διαφορετικά ερωτήματα που έχουν αυτό τον περιορισμό της ημερομηνιάς) μου είναι πιο εύκολο να πάρω όλα τα αποτελέσματα από τη βάση ανεξάρτητα της ημερομηνίας και να τα ξεδιαλέξω στον php κώδικα από το να προσαρμόσω αυτό που λες σε κάθε ένα από τα ερωτήματα μου. Αν δεν υπάρχει εύκολη λύση έτσι θα αναγκαστώ να το κάνω πάντως. ευχαριστώ για την απάντηση.
computeras13 Δημοσ. 21 Μαΐου 2012 Δημοσ. 21 Μαΐου 2012 Δεν είναι θέμα ευκολίας. Απλά εξαρτάται γενικότερα από την υλοποίηση. Όταν παίζεις με πεδία datetime είναι καλύτερο να γίνονται όλες οι σχετικές ενέργειες στον server (αν έχεις ξεχωριστό database server τότε μόνο με SQL). Ο λόγος που το λέω αυτό είναι για να αποφύγεις προβλήματα αποσυγχρονισμού ώρας κτλ. Σκέψου το εξής, έχεις μιας εφαρμογή που τρέχει σε διάφορους υπολογιστές (client side) και τραβάει την ώρα από εκεί για την αποθηκεύσει στην βάση. Ο κάθε υπολογιστής όμως δεν είναι σίγουρο οτι έχει σωστή ώρα. Οπότε αυτό σου δημιουργεί προβλήματα στην βάση. Αυτό μπορεί να ισχύει ακόμα και όταν έχεις διαφορετικό database server και διαφορετικό application server. Στην δική σου περίπτωση όμως (που είναι για εργασία), υποθέτω οτι όλα τρέχουν σε ένα server, οπότε δεν θα έχεις πρόβλημα είτε γίνονται οι ενέργειες μέσω sql είτε μέσω php (εφόσον ο κώδικας της php ούτως ή άλλως είναι server sided και δεν τραβάς την ώρα από τον κάθε client). Απλά στα αναφέρω για να τα έχεις στο μυαλό σου γενικότερα οτι είναι καλύτερο να τα κάνεις αυτά με sql για να έχεις το κεφάλι σου ήσυχο σε κάθε περίπτωση.
karabouzouk... Δημοσ. 21 Μαΐου 2012 Μέλος Δημοσ. 21 Μαΐου 2012 Δες εδώ Είναι ένα απ αυτά που δοκίμασα.. αλλά αυτό που επιστρέφει είναι τύπου dateInterval και δεν μπόρεσα να το συγκρίνω με 40 (μέρες) για παράδειγμα. ευχάριστώ για την απάντηση! Δεν είναι θέμα ευκολίας. Απλά εξαρτάται γενικότερα από την υλοποίηση. Όταν παίζεις με πεδία datetime είναι καλύτερο να γίνονται όλες οι σχετικές ενέργειες στον server (αν έχεις ξεχωριστό database server τότε μόνο με SQL). Ο λόγος που το λέω αυτό είναι για να αποφύγεις προβλήματα αποσυγχρονισμού ώρας κτλ. Σκέψου το εξής, έχεις μιας εφαρμογή που τρέχει σε διάφορους υπολογιστές (client side) και τραβάει την ώρα από εκεί για την αποθηκεύσει στην βάση. Ο κάθε υπολογιστής όμως δεν είναι σίγουρο οτι έχει σωστή ώρα. Οπότε αυτό σου δημιουργεί προβλήματα στην βάση. Αυτό μπορεί να ισχύει ακόμα και όταν έχεις διαφορετικό database server και διαφορετικό application server. Στην δική σου περίπτωση όμως (που είναι για εργασία), υποθέτω οτι όλα τρέχουν σε ένα server, οπότε δεν θα έχεις πρόβλημα είτε γίνονται οι ενέργειες μέσω sql είτε μέσω php (εφόσον ο κώδικας της php ούτως ή άλλως είναι server sided και δεν τραβάς την ώρα από τον κάθε client). Απλά στα αναφέρω για να τα έχεις στο μυαλό σου γενικότερα οτι είναι καλύτερο να τα κάνεις αυτά με sql για να έχεις το κεφάλι σου ήσυχο σε κάθε περίπτωση. Τελικά το υλοποίησα όπως το είπες >"... DATEDIFF(curdate(), last_update) <= " . $recency . "..." έτσι όλα γίνονται μέσα στα ερωτήματα της sql. Που το ξέρεις ότι είναι για εργασία..?! Και μια offtopic ερώτηση.. πώς γίνεται να εκτελεστεί php κώδικας στον client..? Ευχαρστώ για την απάντηση και το χρόνο σου!
computeras13 Δημοσ. 21 Μαΐου 2012 Δημοσ. 21 Μαΐου 2012 Που το ξέρεις ότι είναι για εργασία..?! Αφού κάνεις αναφορά για ερωτήματα, τι ποιο λογικό; Και μια offtopic ερώτηση.. πώς γίνεται να εκτελεστεί php κώδικας στον client..? Απ' όσο ξέρω δεν μπορείς να τρέξεις PHP σε client μιας και είναι server based γλώσσα. Μόνο αν παίξεις σε συνδυασμό με κάτι άλλο (πχ javascript) μπορείς να πάρεις στοιχεία από client. Εγώ αναφερόμουν γενικότερα, όχι απαραίτητα σε PHP.
karabouzouk... Δημοσ. 21 Μαΐου 2012 Μέλος Δημοσ. 21 Μαΐου 2012 Και πώς αλλιώς να τα πω αφού ερωτήματα λέγονται Μυρίζω ψαρίλα θες να μου πεις!? Οκ για την php στον client κατάλαβα..!
computeras13 Δημοσ. 22 Μαΐου 2012 Δημοσ. 22 Μαΐου 2012 Δεν είπα κάτι τέτοιο. Απλά αναφερόμενος σε ερωτήματα είναι λογικό ο άλλος να καταλάβει οτι έχει να κάνει με εργασία σχολής. Δεν θα δεις κάποιον που κάνει ένα project επαγγελματικά να αναφερθεί σε 'ερωτήματα'.
defacer Δημοσ. 22 Μαΐου 2012 Δημοσ. 22 Μαΐου 2012 Καλώς κατέληξες στην SQL λύση μέσω DATEDIFF. Ο λόγος για τον οποίο επιβάλλεται εκτός πολύ σπανίων εξαιρέσεων να κάνεις τη δουλειά σε SQL έχει πολλές συνιστώσες (και κατά την άποψή μου καμία από αυτές δεν έχει να κάνει με διαφορές ώρας -- όχι πως δε μπορεί να συμβεί, αλλά εσένα σαν προγραμματιστή πρέπει να σε απασχολούν πρωτίστως άλλα): Είναι πολύ πιο γρήγορο να γίνει η δουλειά στην database, ειδικά (ανάλογα με το τι κάνεις) υπάρχουν κατάλληλα indexes. Είναι είναι σχεδιασμένη ειδικά για να κάνει τέτοια πράγματα. Σκέψου το σενάριο όπου θέλεις να ταξινομήσεις 100Κ εγγραφές ανά διαφορά ημερομηνίας και να πάρεις από αυτές τις 10 τελευταίες. Αν δεν κάνεις την ταξινόμηση στη database τότε δεν μπορείς επίσης να κάνεις και LIMIT στη database, επομένως η μόνη λύση που σου μένει είναι να τραβήξεις 100Κ εγγραφές, να τις ταξινομήσεις και μετά να τις πετάξεις όλες εκτός από τις 10 που ήθελες. Bad, bad, bad. Ο κώδικας με τα λιγότερα bugs είναι αυτός που δεν έχει γραφτεί. Γιατί να προτιμήσεις να γράψεις κώδικα μόνος σου για μια δουλειά την οποία μπορεί να σου κάνει κώδικας που είναι ήδη γραμμένος με στανταρ πολύ υψηλότερα από αυτά που θα μπορούσες να πιάσεις;
karabouzouk... Δημοσ. 23 Μαΐου 2012 Μέλος Δημοσ. 23 Μαΐου 2012 Καλώς κατέληξες στην SQL λύση μέσω DATEDIFF. Ο λόγος για τον οποίο επιβάλλεται εκτός πολύ σπανίων εξαιρέσεων να κάνεις τη δουλειά σε SQL έχει πολλές συνιστώσες (και κατά την άποψή μου καμία από αυτές δεν έχει να κάνει με διαφορές ώρας -- όχι πως δε μπορεί να συμβεί, αλλά εσένα σαν προγραμματιστή πρέπει να σε απασχολούν πρωτίστως άλλα): Είναι πολύ πιο γρήγορο να γίνει η δουλειά στην database, ειδικά (ανάλογα με το τι κάνεις) υπάρχουν κατάλληλα indexes. Είναι είναι σχεδιασμένη ειδικά για να κάνει τέτοια πράγματα. Σκέψου το σενάριο όπου θέλεις να ταξινομήσεις 100Κ εγγραφές ανά διαφορά ημερομηνίας και να πάρεις από αυτές τις 10 τελευταίες. Αν δεν κάνεις την ταξινόμηση στη database τότε δεν μπορείς επίσης να κάνεις και LIMIT στη database, επομένως η μόνη λύση που σου μένει είναι να τραβήξεις 100Κ εγγραφές, να τις ταξινομήσεις και μετά να τις πετάξεις όλες εκτός από τις 10 που ήθελες. Bad, bad, bad. Ο κώδικας με τα λιγότερα bugs είναι αυτός που δεν έχει γραφτεί. Γιατί να προτιμήσεις να γράψεις κώδικα μόνος σου για μια δουλειά την οποία μπορεί να σου κάνει κώδικας που είναι ήδη γραμμένος με στανταρ πολύ υψηλότερα από αυτά που θα μπορούσες να πιάσεις; Συμφωνώ 100% απλά στην παρούσα φάση η βάση η αλήθεια είναι ότι δεν έχει και τον τέλειο σχεδιασμό και μου φάνηκε καλύτερη ιδέα να το υλοποιήσω στην php αυτό με τις ημερομηνίες.. αλλά λάθος είναι πολύ καλύτερο απ όλες τις απόψεις έτσι! Ευχαριστώ για το χρόνο σου!
Προτεινόμενες αναρτήσεις
Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε
Πρέπει να είστε μέλος για να αφήσετε σχόλιο
Δημιουργία λογαριασμού
Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!
Δημιουργία νέου λογαριασμούΣύνδεση
Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.
Συνδεθείτε τώρα