nicht angemeldet
Bewertung der fertigen Struktur
0 0 0 0 0 0
Bewertung der fertigen Struktur
Hallo
Über die Nacht habe ich meine DB-Struktur aufgrund eurer Tipps in http://forum.de.selfhtml.org/?t=70828&m=407507 überarbeitet und es wäre mir eine Hilfe wenn ihr mir abschliessend eure Meinung dazu sagen könntet. Wo seht ihr Probleme? Fehler? Benennung der Felder? Beziehungen?
tbl_categories:
//Zeigt Kategorien für Produkte, wird für die History-Funktion //benötigt
+---------------+------------------------+
| categories_id | name |
+---------------+------------------------+
| 0 | Notebook |
| 1 | Notebook CD-RW/DVD-ROM |
+---------------+------------------------+
tbl_options
//Zeigt alle Produktoptionen für eine Produkt(Zubehör)
+-----------+----------------------------------+---------------+-----------+
| option_id | name | categories_id | states_id |
+-----------+----------------------------------+---------------+-----------+
| 2 | IBM ThinkPad CD-RW/DVD-ROM Combo | 1 | 1 |
| 1 | IBM ThinkPad DVD-ROM Combo | 1 | 2 |
+-----------+----------------------------------+---------------+-----------+
tbl_products
//Zeigt alle Produkte
+-------------+------------------+---------------+-----------+
| products_id | name | categories_id | states_id |
+-------------+------------------+---------------+-----------+
| 1 | IBM ThinkPad T40 | 0 | 2 |
| 2 | IBM ThinkPad R50 | 0 | 1 |
+-------------+------------------+---------------+-----------+
tbl_products_options
//Ordnet den Produkten bestimmte Optionen zu
+---------------------+-------------+------------+
| products_options_id | products_id | options_id |
+---------------------+-------------+------------+
| 1 | 1 | 1 |
| 2 | 2 | 2 |
+---------------------+-------------+------------+
tbl_states
//Zeigt die verschiedenen Zustände
+-----------+---------------------+
| states_id | name |
+-----------+---------------------+
| 0 | Test |
| 1 | Aktuelles Sortiment |
| 2 | Bestand |
| 3 | Liquidation |
+-----------+---------------------+
Erklärungen:
-Ein Produkt kann keine, eine oder mehrere Optionen haben.
-In einer Kategorie gibt es Produkte und Optionen in den verschiedenen Stati
-Kommt ein Nachfolgeprodukt, verschieben sich die Stati der anderen Produkte um eins nach Hinten.
Gruss Johannes
-
Hello,
Über die Nacht habe ich meine DB-Struktur aufgrund eurer Tipps in [pref:t=70828&m=407507] überarbeitet und es wäre mir eine Hilfe wenn ihr mir abschliessend eure Meinung dazu sagen könntet. Wo seht ihr Probleme? Fehler? Benennung der Felder? Beziehungen?
Welchen Grund hast Du dafür das _id immer hinten anzuhängen?
Jetzt sag bitte aber nicht: weil ich es immer so gesehen hae. (Das wäre kein Grund, sondern Dummheit)Nenn mir bitte ein DBMS das Strings vom Ende her Indiziert.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Hallo Tom
Welchen Grund hast Du dafür das _id immer hinten anzuhängen?
Jetzt sag bitte aber nicht: weil ich es immer so gesehen hae. (Das wäre kein Grund, sondern Dummheit)Na gut, wenn du wirklich drauf bestehst:-) Der Mensch ist aber wirklich ein Gewohnheitstier...
Gruss Johannes
-
Hello,
Welchen Grund hast Du dafür das _id immer hinten anzuhängen?
Jetzt sag bitte aber nicht: weil ich es immer so gesehen hae. (Das wäre kein Grund, sondern Dummheit)Na gut, wenn du wirklich drauf bestehst:-) Der Mensch ist aber wirklich ein Gewohnheitstier...
Früher oder später werden auch Deine Feldnamen mal zu Datenwerten und dann wirst Du sehen, dass es mehr Unterstützung vom DBMS gibt, wenn die Kennung ein Präfix ist.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen -
Hello Johannes,
noch was: Ich sehe gerade, dass ja Dein erster Thread zu diesem Thema noch gar nicht so weit weg war. Ich habe mich jetzt Durch das "über Nacht" etwas verwirren lassen, sonst hätte ich dir in diesem hier gar nicht geantwortet.
Bitte also in Zukeunft keine neuen Threads aufmachen, wenn der erste noch nicht im Archiv ist. Da es doch um dasselbe Thema ging, interessiert das jemanden, der später danach sucht, als vollständige Abhandlung und nicht in Bröckchen.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
Schön, dass sich alle über die Benennung Deiner Felder hermachen. Letztendlich ist das egal. Du solltest aber die REAL Bezeichnungen nehmen, damit auch andere damit was anfangen können.
Wie auch immer. Ich würde die Tabellen optionen_category und produkt_category anlegen. Das ist aber Geschmacksache. Ob's Sinn macht, weißt Du am besten. :-)
Ciao
-
Hello,
Schön, dass sich alle über die Benennung Deiner Felder hermachen. Letztendlich ist das egal. Du solltest aber die REAL Bezeichnungen nehmen, damit auch andere damit was anfangen können.
Wie meinst du das mit den Real-Bezeichnungen, Verona?
Wie auch immer. Ich würde die Tabellen optionen_category und produkt_category anlegen. Das ist aber Geschmacksache. Ob's Sinn macht, weißt Du am besten. :-)
...Sinn hat...
Aber dann einheitlich englisch und einheitlich Singular.
Also auch "product_category" usw.
Da stecken tatsächlich noch Fehler drin.tbl_options
id_option ?Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Da stecken tatsächlich noch Fehler drin.
tbl_options
id_option ?Wo stecken Fehler drin? Im Englisch oder in der Struktur?
-
Hello,
Da stecken tatsächlich noch Fehler drin.
tbl_options <-- Plural
id_option <-- SingularWo stecken Fehler drin? Im Englisch oder in der Struktur?
In der Konsequenz der Namensvergabe:
einheitlich Singular
einheitlich englisch oder deutsch oder italienisch oder ...
gleiche Namen für Primärschlüssel und Tabellen, mit Ausnahme der
vom jeweiligen DBMS unterstützten Präfixe
Manche DB-Developer untrstützen das nämlich aktiv z.B. bei
Erstellung und Auffinden von Relations(möglichkeiten)Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
...ach so...Danke!
-
Ja, genau. Darum heißen bei mir die Dinge nicht ID sondern UID. Übrigens hat Tom recht. Das war ein Schreibfehler von mir. Also entweder Deutsch oder Englisch oder was auch immer.
Zum "Sinn macht" oder "Sinn hat": Das ist mir eigentlich schnuppe. Da, wo ich von weg bin, da sacht man och "als wie"... hehehe
Warum eigentlich immer tbl_... davor schreiben? Das es einen Tabelle ist, ist doch eigentlich klar. Meine Keyspalten heißen auch immer UID und nicht UID_irgendwas. Stelle mir gerade die SQL-Abfrage vor.
SELECT tbl_options.options_id
FROM tbl_options
WHERE tbl_options.options_id =Besser ist doch das hier:
SELECT options.uid
FROM options
WHERE options.uid =oder sehe ich das falsch?!
Vero
PS: Bitte nicht auf Korrektheit in der Syntax achten!
-
Hallo
Besser ist doch das hier:
SELECT options.uid
FROM options
WHERE options.uid =oder sehe ich das falsch?!
Solange es keine Views gibt schon...
Was ist uid? warum nicht id?
Gruss Johannes
-
Hallo Johannes,
Was ist uid? warum nicht id?
unique identification!!! Doppelt gemoppelt! :-)
-
Hello,
unique identification!!! Doppelt gemoppelt! :-)
In der Kürze liegt die Würze...
Das mit dem tbl_ Präfix ist schon nicht schlecht gedacht. Es gibt Datenbanksysteme, da kann man dann später auch Queries und Views (was _fast_ das gleiche ist) speichern und behandeln, als wäre es eine Tabelle. Sie bilden also eine indirekte Datenherkunft. Und da kann man schon mal merkwürdige Dinge bauen, wenn man nicht merkt, dass man statt der Tabelle die bereits manipulierte Zwischenschicht erwischt hat.
Und die Geschichte mit
T_TEST
UID
FELD1
FELD2gegenüber
T_TEST
ID_TEST
FELD1
FELD1löst sich auf, wenn man sich das Kapitel zu Joins und USING anschaut.
Dann kommt nur noch die zweite Variante in Frage.@ Johannes:
Auf einheutliche Groß/Kleinschreibung und einheitliche Unterstrichbenutzung würde ich noch achten. Die Regeln dafür würde ich an Deiner Stelle schriftlich niederlegen und Dir über den Schreibtisch kleben. Ich schreiben in DBs z.B. alle Bezeichner GROSS, weil ich dann später in der PHP-Schnittstelle bei $_POST['FELD1'] gleich erkennen kann, dass dieses Feld zur Datenbindung an die Tabelle vorgesehen ist. Alle Felder, die nur Scriptintern Bedeutung haben, werden dann klein geschrieben. Ist aber nur meine private Hilfskrücke, hat mir aber schon oft Kummer erspart.Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
-
-
-
-
Tach Tom,
Wie meinst du das mit den Real-Bezeichnungen, Verona?
Naja, die richtigen Bezeichnungen und keine Abkürzungen. Anstelle von tbl_opt_pro eher table_options_products. Wobei ich hier auf table ganz verzichten würde.
Mit den Schreibfehlern hast Du natürlich Recht.
Vero
-
-
-
Hi,
meine folgenden Anmerkungen sind "ideologischer" Art.
tbl_categories:
Mir gefaellt die Praefix 'tbl_' nicht. Besser 'CATEGORIES'.
//Zeigt Kategorien für Produkte, wird für die History-Funktion //benötigt
'<Beschreibung>Zeigt welche Produkte zu welcher Zeit welcher Kategorie zugeordnet sind oder waren.</Beschreibung>'
+---------------+------------------------+
| categories_id | name |
+---------------+------------------------+
| 0 | Notebook |
| 1 | Notebook CD-RW/DVD-ROM |
+---------------+------------------------+'categories_id' ist nicht gut, besser 'Category_ID'. 'name' ist nicht gut, bssser 'Category_Name'.
tbl_options
Tabellenname nicht OK, s.o..
//Zeigt alle Produktoptionen für eine Produkt(Zubehör)
'<Beschreibung>Haelt Optionen, auf die von den Produkten verwiesen wird.</Beschreibung>'
+-----------+----------------------------------+---------------+-----------+
| option_id | name | categories_id | states_id |Datenfeldnamen nicht OK, s.o..
+-----------+----------------------------------+---------------+-----------+
| 2 | IBM ThinkPad CD-RW/DVD-ROM Combo | 1 | 1 |
| 1 | IBM ThinkPad DVD-ROM Combo | 1 | 2 |
+-----------+----------------------------------+---------------+-----------+tbl_products
Tabellenname nicht OK, s.o..
//Zeigt alle Produkte
'<Beschreibung>Haelt die Produkte und bildet soz. die Haupttabelle, um die sich andere Tabellen scharen.</Beschreibung>'
+-------------+------------------+---------------+-----------+
| products_id | name | categories_id | states_id |Datenfeldnamen nicht OK, s.o..
+-------------+------------------+---------------+-----------+
| 1 | IBM ThinkPad T40 | 0 | 2 |
| 2 | IBM ThinkPad R50 | 0 | 1 |
+-------------+------------------+---------------+-----------+tbl_products_options
Bsserer Name 'RELATIONS_PRODUCTS_OPTIONS'.
//Ordnet den Produkten bestimmte Optionen zu
+---------------------+-------------+------------+
| products_options_id | products_id | options_id |
+---------------------+-------------+------------+
| 1 | 1 | 1 |
| 2 | 2 | 2 |
+---------------------+-------------+------------+Bessere Namen:
'Relation_Products_Options_ID' statt 'products_options_id'
'Relation_Product_ID' statt 'products_id'
'Relation_Oprion_ID' statt 'options_id'Anmerkung: Es ist zu ueberlegen, ob die Historisierung der Beziehung zwischen der Tabelle 'PRODUCTS' und der Tabelle 'OPTIONS' nicht anders realisiert werden kann. (Beispielsweise ueber eine zweite DB mit dem namen 'DB_HISTORY'. ;-).
tbl_states
Tabellenname nicht OK, s.o..
//Zeigt die verschiedenen Zustände
'<Beschreibung>Haelt Stati...</Beschreibung>'
+-----------+---------------------+
| states_id | name |Datenfeldnamen nicht OK, s.o..
+-----------+---------------------+
| 0 | Test |
| 1 | Aktuelles Sortiment |
| 2 | Bestand |
| 3 | Liquidation |
+-----------+---------------------+Erklärungen:
-Ein Produkt kann keine, eine oder mehrere Optionen haben.
-In einer Kategorie gibt es Produkte und Optionen in den verschiedenen Stati
-Kommt ein Nachfolgeprodukt, verschieben sich die Stati der anderen Produkte um eins nach Hinten.Moeglicherweise habe ich die Beziehungen der Tabellen nicht verstanden, kannst Du vielleicht ein DB-Designdiagramm einbinden?
Gruss,
Lude--
"Ohne Taschengeld, der Hund nicht bellt."-
Hallo Lude
Danke für deine Mühe. Aber deine Vorschläge widersprechen eigentlich den Vorschlägen aller anderer Forumsantworten...?
Gruss Johannes
-
Hi,
Danke für deine Mühe. Aber deine Vorschläge widersprechen eigentlich den Vorschlägen aller anderer Forumsantworten...?
das ist gut. - Wo ist das Diagramm?
Gruss,
Lude---
"Bis Weihnachten brauchen wir Klarheit bei der Maut."-
das ist gut. - Wo ist das Diagramm?
Meinst du sowas ?
<img src="http://www.mueller-heizung.ch/images/struktur.gif" border="0" alt="">
-
Yo!
Meinst du sowas ?
'You've got it.'
Ich bitte meine Anmerkungen in der Folge wiederum als "ideologisch" zu betrachten (diesmal aber als etwas weniger ideologisch ;-):
Du hast Produkte, die kategorisiert werden: 'CATEGORIES'
Diese Produkte kennen Bearbeitungsstaende: 'STATES'
Diese Produkte kennen Optionen: 'OPTIONS'. Produkte kennen mehrere Optionen (in Abhaengigkeit wovon?).Und um die Realiteet besser nachbilden zu kennen, muss die Anforderunglage erklaert werden:
(Ich hab's noch nicht ganz verstanden)Gruss,
Lude--
"Ohne Taschengeld, der Hund nicht bellt." -
yo,
categories und states würde ich überdenken, ob es notwendig ist, für nur den namen jeweils eine tabelle zu benutzen.
options wird in dieser form probleme bereiten, weil in der entity mehrere beziehungen drinne stehen, die da meiner meinung nach nicht sein sollten. die muss man sauber auflösen und neue beziehungstabellen dafür anlegen.
die beziehungstabelle zwischen optionen und produkte braucht keine eigene id, sondern ein zusammengesetzter schlüssel reicht.
Ilja
-
-
-
-
-
yo,
-Ein Produkt kann keine, eine oder mehrere Optionen haben.
ich denke mal, du meinst damit auch, dass eine option auch von mehreren produkten genutzt wird. ansonsten ist es eine 1:n beziehung und du kannst dir die beziehungstabelle tbl_products_options sparen.
warum hat die beziehungstabelle eine extra id und nicht einen zusammengesetzten schlüssel über products_id und options_id ?
-In einer Kategorie gibt es Produkte und Optionen in den verschiedenen Stati
das verwirrt mich. in einer kategorie gibt es mehrere produkte. die optionen sind aber sicherlich doch den produkten zuzuordenen und nicht der kategorie. was ist ein stati ?
tbl_states ist überflüssig. dafür brauchst du keine extra tabelle machen, wenn sowie so nur der name und eine id drinne stehen. der name sollt eindeutig sein und wenn es nur einen wert in der tabelle gibt, reicht es ihn in der produkte tabelle zu lassen. warum ist der in der options-tabelle ?
was soll die categorie_id in der options-tabelle bewirken ? es sollte reichen, wenn sie in der produkte-tabelle ist. was macht die stati_id in der options-tabelle ?
Ilja
-
yo,
-Ein Produkt kann keine, eine oder mehrere Optionen haben.
ich denke mal, du meinst damit auch, dass eine option auch von mehreren produkten genutzt wird. ansonsten ist es eine 1:n beziehung und du kannst dir die beziehungstabelle tbl_products_options sparen.
Eine Option kann auch von mehreren Produkten benutzt werden.
warum hat die beziehungstabelle eine extra id und nicht einen zusammengesetzten schlüssel über products_id und options_id ?
Was meinst du mit zusammengesetzten Schlüssel? Ich habe eine extra ID eingeführt weil die Beziehungen leicht hinzuzufügen/entfernen sein müssen. Zudem gibt es eine History-Funktion
-In einer Kategorie gibt es Produkte und Optionen in den verschiedenen Stati
das verwirrt mich. in einer kategorie gibt es mehrere produkte. die optionen sind aber sicherlich doch den produkten zuzuordenen und nicht der kategorie. was ist ein stati ?
States stellen die verschiedenen stati welche ein Produkt durchläuft, dar. Ein neues Produkt wird zuerst getestet, gelangt dann ins Sortiment, fällt in den Bestand...und wird letztendlich liquidiert. Ein Produkt fällt eine Stufe weiter sobald ein neues kommt...
tbl_states ist überflüssig. dafür brauchst du keine extra tabelle machen, wenn sowie so nur der name und eine id drinne stehen. der name sollt eindeutig sein und wenn es nur einen wert in der tabelle gibt, reicht es ihn in der produkte tabelle zu lassen. warum ist der in der options-tabelle ?
Später möchte ich einem Status vielleicht auch noch andere Eigenschaften zuweisen können
was soll die categorie_id in der options-tabelle bewirken ? es sollte reichen, wenn sie in der produkte-tabelle ist. was macht die stati_id in der options-tabelle ?
In der Kategorie Notebook gibts z.B. ein TP T40, ein TP T50...Im Zusammenhang mit der State-Tabelle muss ich ja wissen, welche Produkte zusammengehören...
Ilja
Johannes
-
yo,
warum hat die beziehungstabelle eine extra id und nicht einen zusammengesetzten schlüssel über products_id und options_id ?
Was meinst du mit zusammengesetzten Schlüssel?
eine eigene id für die beziehungstabelle zu machen ist überflüssig. wenn der schlüssel über die beiden felder der id aus den beiden anderen tabellen geht, ist jeder datensatz eindeutig in der beziehungstabelle.
Später möchte ich einem Status vielleicht auch noch andere Eigenschaften zuweisen können
wenn du über den natürlich schlüssel der stati gehts, kannst du dir erst einmal die tabelle sparen und später hinzufügen, falls es dann überhaupt noch erwünscht ist.
In der Kategorie Notebook gibts z.B. ein TP T40, ein TP T50...Im Zusammenhang mit der State-Tabelle muss ich ja wissen, welche Produkte zusammengehören...
das geht über joins und nicht die tabellenstruktur.
Ilja
-
Hello,
eine eigene id für die beziehungstabelle zu machen ist überflüssig. wenn der schlüssel über die beiden felder der id aus den beiden anderen tabellen geht, ist jeder datensatz eindeutig in der beziehungstabelle.
Das unterscheidet den "Snapshot-Theoretiker" vom "Dynaset-Praktiker"...
Wobei ich mir dei Begriffe Snapshot und Dynaset einfach mal geliehen habe, weil sie mir so gut gefielen.
Snapshot - momentane Datensicht, eingefroren, keine Veränderungen während
der BearbeitungDynaset - Sicht auf einen dynamischen Datenbestand, der sich auch während
der Bearbeitung noch ändern kann. Änderungen an der Sicht wirken
sich sofort auf den Original-Datenbestand aus.Und was meine ich jetzt damit?
Eine Datenbank entwickelt man heute nicht mehr einer starren Struktur für alle Ewigkeit, sondern man ist sich vom ersten tage an darüber bewußt, dass über die Lebensdauer der Datenbank ständig Strukturänderungen und Ergänzungen eintreten werden. Darauf muss man man beim Design nach möglichkeit Rücksicht nehmen. Das ist der wesenetlichste Grund dafür, dass Tabelle grundsätzlich eigene IDs bekommen, auch wenn sich aus zusammengesetzen Schlüsseln eigentlich zum Zeitpunkt der Anlage ein Primärschlüssel erbibt.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
yo,
der wesentliche aspekt, warum datenbanken enstanden sind, ist die ja gerade die datenunabhängigkeit und somit die flexibilität, ein unternehmen zu begleiten und in seiner entwicklung zu unterstützen, anstelle sie zu behindern.
insofern sind es weniger die konstrukte einer datenbank, die eine flexibilität verhindern, sondern mehr das datendesign. ich sehe keinen grund, warum ein zusmmengesetzter schlüssel grundsätzlich gegenüber einen einfachen schlüssel einen nachteil bezüglich der flexibilität besitzen sollte. die gründe die weiter unten aufgeführt wurden, sind folgen eines fehlerhaften datendesigns.
Ilja
-
Hello Ilja,
insofern sind es weniger die konstrukte einer datenbank, die eine flexibilität verhindern, sondern mehr das datendesign. ich sehe keinen grund, warum ein zusmmengesetzter schlüssel grundsätzlich gegenüber einen einfachen schlüssel einen nachteil bezüglich der flexibilität besitzen sollte. die gründe die weiter unten aufgeführt wurden, sind folgen eines fehlerhaften datendesigns.
Selbst das beste Datendesign muss in einem realen Betriebsumfeld mal angepasst und überarbeitet werden. Und da sollte man sich das Leben nicht unnötig schwer machen, indem man die Schlüssel-Integrität und damit die referezielle Integrität der Datenbank gefährdet.
Es ist auch nicht auszuschließen, dass an einer eigentlich geschlossenen DB noch andere externe Datenverwaltungsprogramme (zumindest lesend) andocken. Sowas funktioniert nur bei über die Zeit eineindeutigen Schlüsseln. Diese Schlüssel müssen Daten- und Datenort-unabhängig sein.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
yo,
Selbst das beste Datendesign muss in einem realen Betriebsumfeld mal angepasst und überarbeitet werden. Und da sollte man sich das Leben nicht unnötig schwer machen, indem man die Schlüssel-Integrität und damit die referezielle Integrität der Datenbank gefährdet.
ich sehe das genauso, dass sich die situation immer wieder verändern kann und gegebenenfalls das datendesign zu ändern ist. allerdings ist die aufteilung des zusammengestzten schlüssels in einen eigenen schlüssel meiner meinung nach eher hinderlich als hilfreich. zusammengesetzte schlüssel impleziert nicht weniger flexibilität, zumindestens mir kein bekannter.
Es ist auch nicht auszuschließen, dass an einer eigentlich geschlossenen DB noch andere externe Datenverwaltungsprogramme (zumindest lesend) andocken. Sowas funktioniert nur bei über die Zeit eineindeutigen Schlüsseln. Diese Schlüssel müssen Daten- und Datenort-unabhängig sein.
da kann ich nicht folgen. seit wann sie zusammengesetzte schlüssel nicht eindeutig und eine datenbank ist ja gerade dafür da, das andere programme sie benutzen und daten abrufen,bzw. verändern.
Ilja
-
-
-
-
-
-
Hi,
sag' mal was zum Datenbankdiagramm: [pref:t=70849&m=407847]
Gruss,
Lude-
uppps, am falschen ort gepostet, einfach ein wenig runter scrollen. da ist meine antwort.
Ilja
-
-
Hello,
warum hat die beziehungstabelle eine extra id und nicht einen zusammengesetzten schlüssel über products_id und options_id ?
Das habe wir alles schon durchdiskutiert. Lest doch erstmal, bevor Ihr wieder von vorne anfangt... :-|
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
Hallo,
Zu den Namen ist ja schon vieles gesagt und z.T. auch etwas dogmatisch argumentiert worden. Naja, ich bin da nicht so pingelig;-)
Ich verfolge meist, d.h. wo es nicht zu komischen Auswüchsen kommt, folgende Regeln:
- Tabellen bezeichnen die Art der Daten in Mehrzahl und Englisch, z.B. CATEGORIES, PRODUCTS, OPTIONS.
- ID-Felder bestehen aus ID_ und der Einzahl des Tabellennamens, z.B. ID_CATEGORY, ID_PRODUCT, ID_OPTION.
- Bezeichnungsfelder bestehen aus der Einzahl des Tabellenames und _NAME, z.B. CATEGORY_NAME, PRODUCT_NAME, OPTION_NAME.
(Der Grund ist, dass diese Namen oft in Abfragen gemeinsam vorkommen und so nicht extra gemappt werden müsssen). - Alle anderen Spalten sind englisch und Einzahl, z.B. PRICE, LENGTH, WEIGHT, DELIVERY_DATE usw.
Achja und noch etwas: Ich verwende 0 nie und nimmer als ID-Wert. Sämtliche ABfragen und Übeprüfungen in externer Logik wird dadurch krisensicherer.
Grüße
Klaus-
Hi,
- ID-Felder bestehen aus ID_ und der Einzahl des Tabellennamens, z.B. ID_CATEGORY, ID_PRODUCT, ID_OPTION.
warum nicht z.B. 'Category_ID'?
- Alle anderen Spalten sind englisch und Einzahl, z.B. PRICE, LENGTH, WEIGHT, DELIVERY_DATE usw.
Warum nicht z.B. '<Tabellenname(case sensitive) bzw. Kuerzel(case sensitive)>_Length'?
Achja und noch etwas: Ich verwende 0 nie und nimmer als ID-Wert. Sämtliche ABfragen und Übeprüfungen in externer Logik wird dadurch
krisensicherer.
Ich verwende nie integer-Werte als ID-Werte, warum Du? ;-)
Gruss,
Lude--
"Ideologien und Dogmen beim Datenbank-Design?"-
Hallo,
warum nicht z.B. 'Category_ID'?
Aus reiner Gewohnheit;-)
Prinzipiell ist es mir egal, ob es nun ID_CATEGORY oder CATEGORY_ID heisst. Es mag sein, dass manche Datenbanken dem eine spezielle Bedeutung beimessen, andere tun es wiederum nicht. Für meine Bedürfnisse haben meine Regeln immer noch gereicht.
Warum nicht z.B. '<Tabellenname(case sensitive) bzw. Kuerzel(case sensitive)>_Length'?
Weil es mir einfach lange vorkommt und bei diesen Feldern die Gefahr einer zweifachen Verwendung des Bezeichners in Queries geringer ist als im Falle der ID- und Bezeichnungsspalte.
Ich verwende nie integer-Werte als ID-Werte, warum Du? ;-)
Weil es Datenbanken gibt, die keine Alternative anbieten und überhaupt, was spricht denn gegen Integer-ID-Werte?
Grüße
Klaus-
Hi,
Warum nicht z.B. '<Tabellenname(case sensitive) bzw. Kuerzel(case sensitive)>_Length'?
Weil es mir einfach lange vorkommt und bei diesen Feldern die Gefahr einer zweifachen Verwendung des Bezeichners in Queries geringer ist als im Falle der ID- und Bezeichnungsspalte.
es ging mir um die DB weit eindeutigen Datenfeldnamen.
Ich verwende nie integer-Werte als ID-Werte, warum Du? ;-)
Weil es Datenbanken gibt, die keine Alternative anbieten und überhaupt, was spricht denn gegen Integer-ID-Werte?
Wenn der Datenzugriff ueber eine ID erfolgt, die der Client zu Gesicht bekommt, dann koennte es Probleme geben. (BTW - ich kenne einige Web-"Loesungen" mit diesem kleinen Fehlerchen.)
Gruss,
Lude-
Hallo,
es ging mir um die DB weit eindeutigen Datenfeldnamen.
Jaaa, Dir;-)
...was spricht denn gegen Integer-ID-Werte?
Wenn der Datenzugriff ueber eine ID erfolgt, die der Client zu Gesicht bekommt, dann koennte es Probleme geben. (BTW - ich kenne einige Web-"Loesungen" mit diesem kleinen Fehlerchen.)
Und was bitte hat das Datenformat eines Feldes mit seiner Sichtbarkeit bei Client-Anwendungen zu tun?
Und überhaupt, warum darf man die ID nicht sehen?Grüße
Klaus-
Hi,
es ging mir um die DB weit eindeutigen Datenfeldnamen.
Jaaa, Dir;-)
es ging mir darum Deine Meinug einzuholen, ob DB-weit eindeutige Datenfeldnamen einen so grossen Wert darstellen, dass die Nachteile langer Namen nicht schwer genug wirken, dass es sich "lohnt."
Und was bitte hat das Datenformat eines Feldes mit seiner Sichtbarkeit bei Client-Anwendungen zu tun?
Und überhaupt, warum darf man die ID nicht sehen?Wenn besipielsweise Datenzugriife vom Bwoserclient angefordert werden, dann sieht man oft sowas: https://reinraus.europuter.com/cgi-bin/rr-load.pl?WhatToDo=login&Session_GUID=9FC48393-13E8-4DB2-8DAE-0125237292AF - Wenn wir mal annehmen, dass die 'Session_GUID' den Wert '1024' annimmt, dann werden Werte fuer die Session doch erratbar? - Nicht lachen, es gibt mehr "Loesungen" auf diesem Niveau als Du vielleicht denkst. Ist das kein ueberzeugendes Plaedoyer gegen die Verwendung von Integer-DFs als ID? :-)
Gruss,
Lude
-
-
-
-
Hallo zusammen
Ich danke euch für eure Kritik und Vorschläge. So wie ich das sehe hat wohl jeder ein bisschen seine eigene Philosophie, die eine besser, die anderer weniger gut. Ich versuche mir das beste aus euren Vorschläge herauszusuchen und meine DB zu erstellen.
@Tom: Betreffend id_ habe ich auf Präfix gewechselt:-)
Gruss Johannes
-
Hello,
@Tom: Betreffend id_ habe ich auf Präfix gewechselt:-)
Na prima. Es tut ja beides nicht weh, aber die Präfix-Variante hat eben in der Praxis (später) doch noch Vorteile.
Wie Du schon sagtest: Woraus besteht eine Entwicklung?
Ein Teil Kreativität,
ein Teil Philosophie,
ein Teil Erfahrung,
ein Teil Einbildung,
ein Teil Ignoranz,
ein Teil Arroganz,
ein Teil Tradition,
ein Teil Wissen(schaft),
ein Teil Akribie,
ein Teil Schlamperei,
ein Teil Raffgier,
ein Teil Durchhaltevermögen,
ein Teil Hefeweizen
ein Teil Chips,
ein Teil Kaffee,
ein Teil Zigen,...
to be continued
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-