Zitat von
Flogo:
Die Sachen heißen doch immer gleich bzw sind unterschiedlich.
Ein PK, ist ein PK, ist ein PK,...
Und wenn etwas einen Namen hat, warum sollte man so dumm sein und ihn immer wieder anders nennen?
Solange man Quick'nDirty nur DataSets und keinerlei Abbildung in Klassen verwendet mag das nur dumm aussehen, versucht man es aber mal vernünftig zu machen lässt es sich auch noch dumm damit arbeiten.
Zitat von
Flogo:
Ich halte mich im Moment noch ziemlich streng an das Buch, in dem steht dass der PK einer Tabelle immer [TabellenName]_ID heißen soll und ein FK auf diesen möglichst genauso
Kannst du mir vielleicht auch noch den Autor verraten? Schließlich muss ich wissen welche Bücher ich _nicht_ empfehlen kann.
Ich glaube man merkt hier deutlich, dass ich deshalb schon öfter Zank mit solchen
DB Hanseln hatte, die irgendwas hinschludern, Spalten immer wieder anders nennen, nur weil sie zu faul/unfähig sind Aliase in Abfragen zu verwenden. (Da ist so ein Punkt auf den ich etwas allergisch reagiere...)
Zitat:
Ich denke damit werde ich es jetzt versuchen. Wenn ich deinen letzten Beitrag richtig verstehe schlägst du sowas in der Art auch (für Künstler <-> Album) vor.
Und auch das was Yadon gepostet hat deckt sich fast damit (welches Feld ist denn bei dir (Yadon) in der Tabelle ArtistByArtist der PK ?)
Ich habe im zweiten Beitrag nur eine weitere Möglichkeit gezeigt, wie man das Ganze einfach um Alben erweitern kann.
Zitat:
Zitat von
Yadon:
Oh, beinahe hätte ich's vergessen, nutze
ADO und
ACCESS.
Werde ich tun, weil das zufällig im Buch auch benutzt wird
Willst du einen easy Einstieg dann wäre da
Access nur mit
Access zu benutzen, oder eine richtige Mini-
DB (wie Firebird) mit Delphi. Den Sinn in der Kombi Jet (
Access) und Delphi habe ich noch nie kapiert.
DB Design geht mit IbExpert und Firebird
IMHO sogar einfacher und schneller.
