Προς το περιεχόμενο

Προτεινόμενες αναρτήσεις

Δημοσ.

Καλησπέρα,

έχω αναλάβει μια εργασία η οποία στο πρώτο της κομμάτι έχει μια βάση δεδομένων με αρκετούς πίνακες με βασικό αυτόν των πελατών. Στο συγκεκριμένο πίνακα, ο οποίος έχει ως πρωτεύων κλειδί ένα αυτόματο id, θέλω να καταχωρώ έναν πελάτη και σύμφωνα με αυτόν να καταχωρείται ο πελάτης και σε άλλους πίνακες αυτόματα(να ενημερώνονται όλοι οι πίνακες που αναφέρονται στον κάθε πελάτη αυτόματα). Οι υπόλοιποι πίνακες έχουν διαφορετικό αριθμό πεδίων και τους έχω βάλει και ξένα κλειδιά σύμφωνα με αυτόν των πελατών. Μία πρόχειρη απεικόνιση είναι η εξής:

 

Πελάτες(id_ΠΕΛΑΤΗ,ΑΦΜ,ΕΠΩΝΥΜΙΑ,ΤΗΛΕΦΩΝΟ)

 

ΒΙΒΛΙΟ(id_ΒΙΒΛΙΟΥ,id_ΠΕΛΑΤΗ,ΕΠΩΝΥΜΙΑ,ΜΗΝΑΣ)

 

Αν μπορεί κάποιος να μου δώσει ένα μπούσουλα για το πως πρέπει να κινηθώ..

 

ευχαριστώ εκ των προτέρων.

Δημοσ.

Αν εισάγω για παράδειγμα έναν πελάτη να μπαίνει αυτόματα ο πελάτης και στον πίνακα "βιβλίο" αντλώντας τα στοιχεία του από τον πίνακα "πελάτες", ότι αφορά βέβαια τον δεύτερο πίνακα.

Δημοσ.

Μόνο την ΕΠΩΝΥΜΙΑ βλέπω κοινό πεδίο, και αν εγώ κατάλαβα σωστά, τότε εσύ έχεις κάνει λάθος που το έβαλες εκεί...

 

Σε κάθε περίπτωση, ας πούμε ότι μπαίνει πελάτης με νέο id 123. Με τι τιμές θα γεμίσεις τη νέα γραμμή στο ΒΙΒΛΙΟ;

  • Like 1
Δημοσ.

Τα κοινα πεδια θα ειναι σιγουρα το id_πελατη,ο Αφμ και η επωνυμια.συμφωνα με το νεο πελατη που εισαγω θα παει να ενημερωσει τα κοινα πεδια στον πινακα Βιβλιο. Τα υπολοιπα πεδια στον πινακα βιβλιο θελω να ειναι fix.παραδειγμα καθε πελατης που θα μπαινει στο βιβλιο να εχει 12 γραμμες,μια για καθε μηνα.ελπιζω να εγινα αντιληπτος!

 

Sent from my iPhone using Insomnia

Δημοσ.

Και γιατί να τα κουβαλάς όλα αυτά στον ΒΙΒΛΙΟ; Το id_πελατη δεν τα υπονοεί;

 

Πάντως, όπως είπε και ο Kercyn, θα χρειαστείς triggers.

Θα φτιάξεις έναν trigger for insert πάνω στον πίνακα των πελατών.

Κατά την εκτέλεση του trigger, οι νέες γραμμές θα περιέχονται στον εικονικό πίνακα inserted.

Δημοσ.

Τα χρειάζομαι όλα αυτά γιατί πρέπει να εμφανίζονται σε αυτή τη μορφή στον πίνακα. Υπάρχει κάποιο "εύκολο" βιβλίο στο οποίο μπορώ να βασιστώ για όλα αυτά;Και αν έχει κάποιος λίγο χρόνο να μιλήσουμε κάποιο απόγευμα μέσω skype θα του ήμουν αρκετά υπόχρεος. Ευχαριστώ

Δημοσ.

Τα χρειάζομαι όλα αυτά γιατί πρέπει να εμφανίζονται σε αυτή τη μορφή στον πίνακα.

 

Το με τι δομή αποθηκεύονται τα δεδομένα και σε ποιά μορφή εμφανίζονται τα αποτελέσματα ενός query είναι σχεδόν άσχετα πράγματα μεταξύ τους. Δες κανένα εισαγωγικό tutorial για sql joins.

Δημοσ.

Άρα κάνω κανονικά τους πίνακες που χρειάζομαι και αυτά που θέλω να εμφανίζω θα τα πετύχω με joins και queries. Σωστά;

Δημοσ.

"Κανονικά" κάνεις τους πίνακές σου κανονικοποιημένους. Δες τα 1NF μέχρι 3NF (έχει και παραδείγματα). Τα 4NF και 5NF έχουν εφαρμογή μόνο σε πιο σπάνιες περιπτώσεις και δε νομίζω ότι έχει νόημα έστω και να τα δεις στη φάση που είσαι. Και μετά όντως αυτά που θέλεις τα εμφανίζεις με joins.

  • Like 1
Δημοσ.

Έτερον εκάτερον.

 

Η ΒΔ σου "πρέπει" να είναι κανονικοποιημένη ούτως ή άλλως. Αυτό αφορά (μεταξύ άλλων) την ύπαρξη της ίδιας πληροφορίας σε πάνω από ένα μέρη.

 

Αν, για τις ανάγκες της εφαρμογής σου, θέλεις να εκτελείται μία διαδικασία όταν συμβαίνει ένα event σε ένα πίνακα, τότε πρέπει να χρησιμοποιήσεις triggers.

 

Με άλλα λόγια, ενώ τα attributes του πελάτη θα πρέπει να βρίσκονται μόνο στον αντίστοιχο πίνακα, αν εσύ θέλεις να βάζεις και 12 γραμμές στο ΒΙΒΛΙΟ κατά την εισαγωγή νέου πελάτη, τότε δεν αποφεύγεις τον trigger...

Δημοσ.

Με την ευκαιρία να πούμε ότι εαν η εισαγωγή τάδε γραμμών πρέπει απαραίτητα (όσον αφορά τη λογική της εφαρμογής σου) να γίνεται κάθε φορά που π.χ. εισάγεται ένας user, τότε έχεις 2 επιλογές:

  1. Απλά γράφεις κώδικα που μετά από το insert user κάνει και ο,τι άλλο χρειάζεται.
  2. Γράφεις triggers και αφήνεις τη database να το κάνει για σένα.

Οι δύο προσεγγίσεις δεν είναι τελείως ισοδύναμες, αλλά αν υποθέσουμε πως για τη χρήση που θέλεις εσύ κάνουν και οι 2 (πολύ πιθανό ως σίγουρο) τότε η επιλογή είναι ελεύθερη. Σ' αυτή την περίπτωση να σε ενημερώσω ότι το (2) έχει το τεράστιο μειονέκτημα πως με τον τρόπο αυτό το σχετικό business logic της εφαρμογής σου αντί να είναι όλο όμορφα μαζεμένο σε κάποια function σκορπίζεται όχι απλά απο δω κι απο κει αλλά ανάμεσα σε τελείως διαφορετικά πράγματα (τον κώδικα και το σχήμα της βάσης).

 

Γενικά μιλώντας είναι κακή ιδέα και σου συνιστώ να μην το κάνεις. Απλά γράψε κώδικα και δώσε όσα queries χρειάζονται για να γίνει αυτό που θέλεις. Θα είναι και ευκολότερο για σένα.

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
  • Δημιουργία νέου...