Πρώτα Βήματα - Βάσεις δεδομένων

Απ: Πολλοί πίνακες ή ένας?

gspiros — Sun, 17 Aug 2008 02:01:01 GMT

Όπως το φαντάζομαι εγώ δεν πρέπει να είναι πολύ δύσκολο.

Θα πρέπει να βάλεις ένα trigger στην βάση, όπου θα τρέχει κάθε φορά που προσθέτεις ένα row στους πίνακες hotel, article, photos κτλ...
Αυτό που θα γίνεται είναι να προσθέτει ένα νέο ID στον πίνακα Entities και στην συνέχεια θα βάζει αυτό το ID σε εκείνο το row που πρόσθεσες, με αποτέλεσμα να υπάρχει ένα column με μοναδικό ID στους πίνακες hotel, article, photos κτλ...

Τώρα που το διαβάζω, μου φαίνεται ότι η βάση θα κάνει πολύ δουλειά για το (σχεδόν) τίποτα...
Έτσι γίνεται ή υπάρχει πιο εύκολος τρόπος?

Απ: Πολλοί πίνακες ή ένας?

George J. Capnias — Fri, 15 Aug 2008 21:10:49 GMT

MakisCE:

Η απορία μου παραμένει, αν αυτό που πρότεινα (βλ. διάγραμμα) έχει δυσκολία στο Insert

"πιθανόν να είναι μπελάς στο insert ενός Article/Hotel/etc,
μιας και πρώτα πρέπει να μπει εγγραφή στο CommentableEntities και το ID Που θα πάρει εκεί, θα είναι το uniqueID (foreign key) στον Articles πχ."

Εννοείς ότι υπάρχει πρόβλημα να ξέρεις ποιο είναι το νέο ID που έχει το record που μόλις πρόσθεσες; Υπάρχουν λύσεις για αυτό...

Δεν το προσδιορίζει η βάση, το υπολογίζεις και εισάγεις εσύ στην βάση, άρα το ξέρεις εκ των προτέρων
Μπορείς να χρησιμοποιήσεις ένα store procedure να σου κάνει την εγγραφή στον πίνακα που θες, και αυτό είναι σε θέση να σου γυρίσει το ID

George J.

Απ: Πολλοί πίνακες ή ένας?

MakisCE — Fri, 15 Aug 2008 19:48:40 GMT

Συμφωνώ και επαυξάνω

αν και η τάση είναι για [user|search]-friendly-urls που ενδείκνυνται για web εφαρμογές.. αλλά αυτό προχωράει ακόμα περισσότερο
π.χ.
/hotels.aspx?id=141   (int, OK)
/hotels.aspx?id=7BE3D24CE5-F2A0-4B16-A39C-7AB17525F07C (guid, ugly)
/hotels.aspx?hid=dotnetseaview      (human readable unique key, made automatically or by human entry, better)
/hotels/dotnetseaview      (url rewriting, mvc frameworks & routing, nice & friendly)

οπότε μια καλή λύση είναι τα GUIDs, χωρίς έξτρα πίνακες, (μόνο Comments και Hotels/Articles/...) αρκεί να μπορείς να έχεις και custom κλειδιά

Η απορία μου παραμένει, αν αυτό που πρότεινα (βλ. διάγραμμα) έχει δυσκολία στο Insert

"πιθανόν να είναι μπελάς στο insert ενός Article/Hotel/etc,
μιας και πρώτα πρέπει να μπει εγγραφή στο CommentableEntities και το ID Που θα πάρει εκεί, θα είναι το uniqueID (foreign key) στον Articles πχ."

Απ: Πολλοί πίνακες ή ένας?

George J. Capnias — Fri, 15 Aug 2008 18:34:22 GMT

MakisCE:

με χρήση GUID είναι ένας τρόπος
έχει το κόστος του όμως, και είναι άσχημος αν πρέπει να εμφανίσεις το GUID, πχ. articles.aspx?id=7BE3D24CE5-F2A0-4B16-A39C-7AB17525F07C

Μπορείς να κάνεις και άλλα πράγματα:

Για να φτάσεις σε μια εγγραφή πρέπει να έχεις ένα μοναδικό κλειδί. Σε αυτή την περίπτωση, αυτό που έχεις "έτοιμο και σερβιρισμένο" είναι το primary key του table σου. Αυτό δεν σε εμποδίζει να φτιάξεις ένα δεύτερο, ή ένα τρίτο μοναδικό κλειδί. Θα μπορούσες να χρησιμοποιήσεις ένα τίτλο, περιγραφή, για να φτιάξεις κάτι που είναι καλύτερα human readable unique key, και από το unique intendifier και από αριθμό. Είναι μια στάνταρντ τεχνική που όλο και περισσότερα weblog engines υιοθετούν τον τελευταίο καιρό...

George J.

Απ: Πολλοί πίνακες ή ένας?

MakisCE — Fri, 15 Aug 2008 01:37:50 GMT

αλήθεια, υπάρχει άλλος τρόπος να έχεις "unique keys across (some) tables"?
(χωρίς χρήση stored proc, triggers, κλπ)

-- edit--

απαντάω μόνος μου για να μη κάνω κι άλλο post

με χρήση GUID είναι ένας τρόπος
έχει το κόστος του όμως, και είναι άσχημος αν πρέπει να εμφανίσεις το GUID, πχ. articles.aspx?id=7BE3D24CE5-F2A0-4B16-A39C-7AB17525F07C

Απ: Πολλοί πίνακες ή ένας?

MakisCE — Fri, 15 Aug 2008 01:35:07 GMT

σχεδιάγραμμα αυτού που πρότεινα

το 4) του cap το έχω χρησιμοποιήσει και μου έχει σπάσει τα νεύρα με τα where typeID=X Που πρέπει να βάζεις συνέχεια.

αυτό που προτείνω δεν το έχω χρησιμοποιήσει (!) πιθανόν να είναι μπελάς στο insert ενός Article/Hotel/etc,
μιας και πρώτα πρέπει να μπει εγγραφή στο CommentableEntities και το ID Που θα πάρει εκεί, θα είναι το uniqueID (foreign key) στον Articles πχ.

Το δικό σου (1) πάντως (ξεχωριστοί Comments πίνακες για κάθε οντότητα), είναι κατά τη γνώμη μου το χειρότερο..
-- εντελώς αντίθετο από DRY (Dont repeat yourself) principles, και το βρίσκεις συνέχεια μπροστά σου να σου θυμίζει τη μ...ία επιλογή που έκανες! LOL

Απ: Πολλοί πίνακες ή ένας?

gspiros — Fri, 15 Aug 2008 01:23:09 GMT

Αχαα, κατάλαβα!
Απλά θα πρέπει το ID αυτού του πίνακα να αυξάνεται κάθε φορά που προσθέτουμε οτιδήποτε.
Είναι πιο εύχρηστη αυτή η μέθοδος από την 4 του cap?
Χρησιμοποιείται σε μεγάλες εφαρμογές?

Απ: Πολλοί πίνακες ή ένας?

MakisCE — Fri, 15 Aug 2008 01:19:06 GMT

spiro, αυτό που πρότεινα, υλοποιεί στην ουσία αυτό που περιέγραψε και ο cap sto 1)

"Αν έχεις ένα πραγματικα μοναδικό, database-wide primary key το οποίο δεν υπάρχει περίπτωση να επαναληφθεί πουθενά, τότε μπορείς να χρησιμοποιήσεις αυτό το key ως foreign key στον πίνακα των σχολίων σου και να υλοποιήσεις τα σχόλια με τη χρήση ενός και μόνο πίνακα."

O CommentableEntities πίνακας , με πεδίο μόνο ένα ID, δίνει ένα database-wide primary key σε όσες οντότητες θέλουμε να παίρνουν comments.

αργότερα θα ανεβάσω κάπου κι ενα database diagram που είχα φτιάξει εχθές

Απ: Πολλοί πίνακες ή ένας?

gspiros — Thu, 14 Aug 2008 22:38:28 GMT

Σας ευχαριστώ όλους!

Αυτό όμως που δεν έχω καταλάβει είναι ο τρόπος που πρότεινε ο MakisCE...
Αν μπορείς εξήγησέ τον!

Απ: Πολλοί πίνακες ή ένας?

cap — Thu, 14 Aug 2008 21:54:11 GMT

Δεν υπάρχει, κατά την άποψή μου, καλύτερος και χειρότερος τρόπος, όλα εξαρτώνται από τις δυνητικές απαιτήσεις του περιβάλλοντος το οποίο θέλεις να υλοποιήσεις.

Ας δούμε λίγο τα δεδομένα μας:

Το πρόβλημά σου είναι οτι έχεις ένα μάτσο πίνακες με διάφορες οντότητες (ξενοδοχεία, φωτογραφίες κλπ) οπου, φυσικά, ο καθένας έχει primary key αλλά αυτό το primary key δεν είναι μοναδικό στο σύνολο των πινάκων, με αποτέλεσμα δυο διαφορετικές οντότητες (που εκφράζονται από δύο διαφορετικούς πίνακες) να ενδέχεται να έχουν το ίδιο primary key. Γι'αυτό και η λύση του να χρησιμοποιήσεις το id της οντότητας σε ένα και μοναδικό πίνακα που κρατάει τα σχόλια δεν είναι εφικτή.

Οι πιθανές λύσεις είναι:
1. Αλλαγή του data type των primary keys των οντοτήτων που σε ενδιαφέρουν σε κάτι πραγματικά unique (uniqueidentifier ή ένα calculated field που θα προκύπτει από το identity αλλά θα παίρνει και κάποιο πρόθεμα ανάλογα με τον πίνακα - τζιζ). Αν έχεις ένα πραγματικα μοναδικό, database-wide primary key το οποίο δεν υπάρχει περίπτωση να επαναληφθεί πουθενά, τότε μπορείς να χρησιμοποιήσεις αυτό το key ως foreign key στον πίνακα των σχολίων σου και να υλοποιήσεις τα σχόλια με τη χρήση ενός και μόνο πίνακα.
2. Χρήση ενός πίνακα σχολίων για κάθε οντότητα που σχολιάζεται, στην ουσία δηλαδή "ζευγάρια" πινάκων - ενας για την οντότητα, ένας για τα σχόλια. Πρακτικό μεν, πολύ δουλειά όμως για τα διαφορετικά queries στα οποία τελικά αλλάζουν μόνο δύο ονόματα πινάκων, συν καθόλου ελαστικότητα στην περίπτωση προσθήκης νέων οντοτήτων στο σύστημα.
3. Χρήση ενός πίνακα σχολίων για όλες τις οντότητες, αλλά με αρκετές κολώνες που λειτουργούν σαν foreign keys, μια για κάθε οντότητα που έχεις στο σύστημά σου και μπορεί να σχολιαστεί. Πρακτικά επαρκές, ανελαστικό όμως όπως και το (2) συν το οτι έχεις λιγοστούς τρόπους να εξασφαλίσεις integrity αν τυχόν γραφτεί τιμή σε παραπάνω από ένα πεδίο σε ένα record.
4. Χρήση ενός πίνακα σχολίων για όλες τις οντότητες, με ένα επιπρόσθετο πεδίο το οποίο υποδεικνύει την οντότητα που αφορά η συγκεκριμένη γραμμή (και απαραίτητα ένα index εκεί επάνω). Π.χ. "H" για ξενοδοχεία, "P" για φωτογραφίες. Ετσι, ανάλογα με ποιά οντότητα ασχολείσαι, μπορείς να έχεις ένα WHERE στα queries σου του στυλ WHERE id=xxx AND type=y οπου θα είσαι σίγουρος οτι θα επιστρέφεται μόνο μια εγγραφή τη φορά. Ευέλικτο, ανοικτό στην προσθήκη νέων οντοτήτων, αλλά απαιτεί την αυθαίρετη παραδοχή οτι θα συμβολίζεις κάθε οντότητα με ένα "καρφωτό" σύμβολο (γραμμα, αριθμό κλπ).

Προσωπικά, αν είχα τη δυνατότητα, θα προτιμούσα τη λύση (1), ενώ αν δεν την είχα λόγω συνθηκών θα προτιμούσα αμέσως μετά τη λύση (4).

Απ: Πολλοί πίνακες ή ένας?

gspiros — Thu, 14 Aug 2008 21:34:47 GMT

Λοιπόν, σε κάποια σελίδα πχ Photos.aspx υπάρχουν φωτογραφίες όπου κάποιος μπορεί να βάλει comments, σε κάποια άλλη σελίδα πχ Hotels.aspx (τα hotels είναι άσχετα με τις photos), κάποιος μπορεί να βάλει comments σε ξενοδοχεία, σε κάποια άλλη σελίδα υπάρχουν άρθρ, όπου κάποιος μπορεί να βάλει comments (τα άρθρα είναι άσχετα με τα ξενοδοχεία και τις φωτογραφίες...) κτλ....
Προφανώς όταν κάποιος ανοίγει κάποια σελίδα, εκτός από τις φωτογραφίες ή τα ξενοδοχεία κτλ, θα εμφανίζονται και τα comments που έχουν σχέση με το αντικείμενο που βλέπει (photo ή hotel ή article κτλ).

Αν τελικά χρησιμοποιήσουμε την δεύτερη μέθοδο, θα πρέπει να υπάρχει κάποιο ID, όπου να μας λέει ότι θέλουμε τα comments για photos (πχ ID=2) και επίσης ότι θέλουμε τα comments για την συγκεκριμένη photo (πχ photoID=3).
Δεν μπορούμε να βάλουμε απλά ID=5, διότι μπορεί να υπάρχει photoID=5, αλλά και HotelID=5.
Κάτι σαν 2 Keys σε ένα πίνακα (τον Comment).
Ελπίζω να σε διαφώτησα...

Η βασική μου ερώτηση είναι πως μπορεί να υλοποιηθεί κάτι παρόμοιο.
Ποιά είναι η καλύτερη μέθοδος?

Απ: Πολλοί πίνακες ή ένας?

George J. Capnias — Thu, 14 Aug 2008 21:13:58 GMT

Η δεν κατάλαβα καλά, ή δεν έχει ξεκαθαριστεί το ζητούμενο:

Ωραία και έχω ένα σχόλιο. Τι είναι αυτό που με ενδιαφέρει σχετικά με το σχόλιο;

Να μπορώ να βρω για ένα item σε σχέση με το mainID του τι σχόλια έχει;
Να μπορώ να ξέρω πόσα σχόλια υπάρχουν σε κάθε κατηγορία;
Να μπορώ να δω ξεκάρφωτα σχόλια;

Υπάρχει κάτι άλλο που με ενδιαφέρει;

Δεν μπορώ να δω το λόγο που σώνει και καλά πρέπει να υπάρχει το typeID, με την προυπόθεση ότι κάθε τύπος έχει δικό table και όλα τα σχόλια ένα table...

George J.

Απ: Πολλοί πίνακες ή ένας?

gspiros — Thu, 14 Aug 2008 19:16:16 GMT

Καλημέρα!
Ο λόγος που έβαλα το typeID είναι ακριβώς αυτός που είπε ο MakisCE!

Βασικά θα ήθελα να ξέρω αν υπάρχουν και άλλα μειωνεκτήματα με αυτούς τους τρόπους.
MakisCE, αν μπορείς εξήγησε λίγο περισσότερο το τελευταίο σου post, διότι με μπέρδεψες...

Εγώ σκοφτόμουν ότι ο 1ος τρόπος που ανέφερα είναι πιο γρήγορος και σίγουρα με αυτόν είναι πιο οργανωμένα τα δεδομένα, διότι έχουμε τα comments σε διαφορετικούσ πίνακες.
Θα μπορούσα να γράψω μια συνάρτηση (ή stored procedure) όπου να παίρνει σαν όρισμα ένα string (όπως hotels, articles κτλ) κάπως έτσι:
function mpla(string x)
"INSERT INTO "+x+"VALUES ........"
είναι όμως σωστός προγραμματισμός αυτός?

Με τον δεύτερο τρόπο, όλα είναι πιο αυτοματοποιημένα, αλλά και πάλι θα πρέπει να παιρνιέται μια παράμετρος string (όπως παραπάνω), αναλόγως αν κάνω add comment σε photo ή σε article. Έχει κανείς καμιά ιδέα?

Απ: Πολλοί πίνακες ή ένας?

MakisCE — Thu, 14 Aug 2008 13:01:34 GMT

μια λύση (δεν ξέρω πόσο valid είναι) θα μπορούσε να είναι η εξής:

CommentableEntities -- id

Hotels -- CommentableEntityID, name, rooms, location, ...

Articles -- CommentableEntityID, title, content, publishDate, ...

Comments -- id, CommentableEntityID, userID, content, ...

Τοποθετούμε μια έξτρα ιεραρχία δηλαδή, όπου όλα τα entities που παίρνουν comments είναι CommentableEntities,
και έτσι πάιρνουν ένα εννιαίο id (unique, auto), κι έτσι το schema είναι κάπως έτσι:

Comments <-- CommentableEntities <--> Hotels, Articles, etc

δεν έχω ιδέα πόσο στέκει το design αυτό, και λαμβάνοντας υπόψιν οτι ξημερώνει, δεν έχει και πολλές πιθανότητες

από τα enities (Hotels, κλπ) παίρνουμε κατευθείαν τα Comments (join στο CommentableEntityID),
δεν ξέρω κατά πόσο θα είναι πονοκέφαλος στα insert ενός "CommentableEntity"

Απ: Πολλοί πίνακες ή ένας?

MakisCE — Thu, 14 Aug 2008 12:12:49 GMT

Γιώργο, ή δεν κατάλαβα καλά την απάντησή σου, ή υπάρχει το εξής πρόβλημα.

αν δεν έχουμε typeID, παρά μόνο mainID, τότε το mainID με value=1 ας πούμε, δεν θα ξέρουμε αν είναι το PhotoID=1, ή το hotelID=1, κλπ

σε παρόμοιο πρόβλημα, έχω 'κληρονομήσει' μια βάση που το λύνει με τον 2ο τρόπο του gspirou, αλλά πρέπει συνέχεια να βάζεις "WHERE typeID=3" (για Hotels ας πούμε) κλπ
-- Ο πίνακας Types με κολώνες: typeID, typeName είναι σχεδόν προεραιτκός, απλά πληροφοριακός
δεν μου είχε αρέσει αυτή η λύση...

ίσως επανέλθω με κάτι ποιο επικοδομητικό!