Wie "plant" ihr eure Datenbanken - wie erstellt ihr DB-Modelle?

[Jamson]

Hallo.

Ich möchte ein eigenes Forum schreiben. Es ist aber wesentlich komplexer als ein normales und bevor ich nun einfach drauf lostippe, möchte ich mir um die Datenbank Gedanken machen.

Bisher ging das bei mir mit DIN A4 Blättern (vielen) und einem Kugelschreiber.

Wie macht ihr das? Nutzt ihr bestimmte Programme die paralell den SQl-Code erzeugen? Es wird eine MySQL-Datenbank - eventuell wird daraus später PostGreSQL. Naja SQL aufjedenfall.

Also wie plant ihr eure größeren Projekte?

Gruß,

Jamson

[Cheatah]

Hi,

Bisher ging das bei mir mit DIN A4 Blättern (vielen) und einem Kugelschreiber.

Wie macht ihr das?

ich mache das komplett anders: mit einem Bleistift ;-)

Nutzt ihr bestimmte Programme die paralell den SQl-Code erzeugen?

Nein, eher umgekehrt. Ich bevorzuge Handarbeit, d.h. ich schreibe die CREATE-Statements selbst (oder nutze gerade mal noch PhpMyAdmin, dessen Zuverlässigkeit ich einschätzen kann). Selten kommt es vor, dass ich mir am Ende ein UML-Diagramm zeichnen lasse.

Also wie plant ihr eure größeren Projekte?

Mit Hirn, Hand und Herz.

Cheatah

[hotti]

hi,

Also wie plant ihr eure größeren Projekte?

Mit einem klaren Kopf, evntl. ner guten Zigarre und am liebsten bei einem Spaziergang. Bevor ich in die Tasten haue, muss das Konzept stehen. Notizen mache ich auch. Finger weg vom Computer in dieser Phase!

Früher hab ich gleich zur Tastatur gegriffen, das ging jedoch nicht immer gut, nicht selten endete sowas in einer Sackgasse und einem vertanem Arbeitstag. Diese Arbeitsweise hab ich mir daher abgewöhnt.

Sicher gibts da auch kuriose Orte, an denen ich heute creativ bin, aufm Klo, unter der Dusche, auf dem Weg mit dem Rad in die Firma, im Thüringer Wald und auch mal im Harz oder im Schwarzwald. Aber wenn dann alles "steht" ists nur noch Tipparbeit und prompt stellen sich da auch Erfolge ein.

Viel Erfolg ;-)
Hotte

[stareagle]

Moin,

Ich möchte ein eigenes Forum schreiben. Es ist aber wesentlich komplexer als ein normales und bevor ich nun einfach drauf lostippe, möchte ich mir um die Datenbank Gedanken machen.

Du solltest dir nicht nur um die Datenbank, sondern gleichzeitig oder noch vor der Datenbank Gedanken um die Architektur deiner Software machen.

Bisher ging das bei mir mit DIN A4 Blättern (vielen) und einem Kugelschreiber.

Ich nutze zwar einen Bleistift... Papier und Bleistift/Kugelschreiber sind meiner Meinung nach eines der wichtigsten, wenn nicht das wichtigste Arbeitsmittel für die Softwareentwicklung - vor den ganzen tollen Tools, die versprechen einem die Arbeit zu erleichtern.

Wie macht ihr das? Nutzt ihr bestimmte Programme die paralell den SQl-Code erzeugen? Es wird eine MySQL-Datenbank - eventuell wird daraus später PostGreSQL. Naja SQL aufjedenfall.

Das kommt auf das Projekt an. Zuerst einmal würde ich versuchen, das ganze so weit wie möglich unabhängig von einer konkreten Programmiersprache oder Datenbank zu planen. Zu empfehlen ist die Verwendung eines objektorientierten Softwaredesigns.

Wenn das grundsätzliche Design steht (Klassen etc.) geht es an die Technologieauswahl (natürlich kann es sein das aufgrund vorhandener Kenntnisse, Vorgaben "von oben", etc. die Auswahl hier nicht ganz frei ist). Dabei wäre dann z.B. zu prüfen, ob es notwendig ist, das ganze speziell auf eine Datenbank abzustimmen. Wenn möglich würde ich hier Technologien wie z.B. PDO verwenden, die die verwendete Datenbank abstrahieren. Ob man die SQL-Statements selbst schreibt, ist eine weitere Entscheidung, die man treffen muss. Wenn das Projekt z.B. in Java umgesetzt werden soll. würde ich die Verwendung der JPA in Erwägung ziehen.

Das sind natürlich alles nur Beispiele.

Also wie plant ihr eure größeren Projekte?

Wie oben bereits zu Anfang gesagt geht es normalerweise mit Papier und Bleistift los. Später kommen dann eventuell UML-Diagramme und/oder ERM-Diagramme hinzu. Dazu gesellen sich eventuell einige kleine Prototypen, in denen man verschiedene Technologien ausprobiert.

Gruß

Stareagle

[Jamson]

Hey,

danke für deine ausführlichen Beschreibungen.
Aber das habe ich schon hinter mir.
Das Forum ist nur ein Teil eines größeren Projektes.

Das ganze läuft über PHP, AJAX mit MySQL und nutzt als Schnittstelle die MySQl-Erweiterung MySQLi. Das Projekt ist komplett OOP und auf dem MVC-Pattern aufgebaut. Valides, W3C-konformes XHTML und CSS ist selbstverständlich ;).

Mich interessiert nur wie hier die Datenbank-Modelle plant. Denn bisher war es oft so das ich dann mal 3 Din A4 Blätter hatte - wenn alles perfekt aufgeschrieben war und dann ist es einfach manchmal schwerer da Überblick zu behalten.

So fallen mir ganz spontan zum Forum schonmal folgendes ein:

Tabelle User (schon vorhanden)

forum_categorys (mit den Kategorien)
forum_threads (Die einzelnen Themen, Erstellungsdatum, Anzahl der Posts)
forum_posts (die einzelnen Beiträge zu den Threads)
forum_invisible_threads (user haben die möglichkeit threads auszublenden)
forum_thread_votes (user haben die möglichkeit threads zu bewerten)
forum_post_votes (user haben die möglichkeit einzelne posts zu bewerten)

Mir fallen sicher noch 5 weitere ein und da ich jeweils auch noch die spalten angebenwill - logisch - wird das nichts mit 2,3 blättern.

Gruß,

Jamson

[Cheatah]

Hi,

forum_categorys (mit den Kategorien)

ich habe mir angewöhnt, Tabellennamen immer im Singular zu halten. Allzu oft selektiert man über mehrere Tabellen hinweg und muss daher Tabellen- und Spaltennamen verknüpfen - dort habe ich aber immer nur *einen* Datensatz vor mir. "WHERE category.id = thread.category" o.ä. ist einfach logischer als das ganze im Plural.

Und wenn es doch der Plural sein soll, dann schreib bitte wenigstens die categories richtig ;-)

Mir fallen sicher noch 5 weitere ein und da ich jeweils auch noch die spalten angebenwill - logisch - wird das nichts mit 2,3 blättern.

Ja, aber beschränke Dich hier auf die wichtigsten Spalten, nämlich die, die Du für die Verknüpfungen und die offensichtliche Sinnhaftigkeit benötigst. Das Feinkonzept kann[1] in digitaler Form geschehen; wichtig sind die Beziehungen zwischen den Tabellen, schon über die Indexe kann man streiten. Und ob Du nun (beispielsweise) Vor- und Nachname einer Person voneinander trennst ist unwichtig, solange Du auf diese Informationen nicht anderweitig im Datenmodell zugreifst.

Das Papier ist eine Denkstütze für Dich. Es braucht nicht aufbewahrt zu werden, und nur diejenigen, die gerade an der selben Geschichte mit Dir zusammenarbeiten, müssen verstehen, was darauf passiert. Versuche nicht, archivierungstauglich zu zeichnen. Notiere die Gedanken, bei denen Du Gefahr läufst, sie nicht lange genug im Gedächtnis[2] halten zu können. Und schmeiße das Papier weg, sobald Du die Denkstütze nicht mehr benötigst. Ernsthaft :-)

Cheatah

[1] Und sollte unbedingt vor Beginn der Implementierung.
[2] ... derjenigen Personen, die gerade daran arbeiten ...

[Ilja]

yo,

Bisher ging das bei mir mit DIN A4 Blättern (vielen) und einem Kugelschreiber.

ich denke mal aus den beiträgen ist klar geworden, dasss stift und papier durchaus ein valides mittel ist, um ideen festzuhalten. allerdings sollte das mit hand geschriebene papier nicht die entgültige fassung sein. es dient halt dem brainstorming und erstentwurf. aber da hört es dann nicht auf, sondern fängt erst an.

am ende sollte immer ein daten-diagramm vorhanden sein und zwar in einer ordentlichen und rechnergestützten form. ich persönlich bevorzuge E/R modelle gegenüber UML. es gibt heutzutage schon wirklich gute tools (schau mal bei der firma Quest Software vorbei). die frage ist immer, ob man auch bereit ist, geld dafür zu investieren. eventuell findet man ein gutes programm, dass frei verfügbar ist. meiner meinung nach lohnt es sich aber zu investieren, da man im laufe des projektes noch oft änderungen im daten-design vornehmen muss. und dazu ist papier denkbar ungeeignet. die daten-diagramme kannst du dann ausdrucken und wir haben sie anschließend immer für alle sichtbar an die wand "genagelt". nicht ganz unwichtig ist dabei auf eine versionierung zu achten.

auch ist es wichtig zu dokumentieren, wie der server aufgesetzt wurde, also welches dbms mit welcher version, betriebsystem, IP, berechtigungen, verzeichnisse etc. dazu kannst du eine textprogramm wie Word oder ähnliches benutzen. in dieses dokument würde ich noch bestimmte richtlinien mit aufnehmen, wie zum beispiel schon gesagt wurde, tabellennamen immer im singular zu halten, ob es präfixe gibt, wie man den primarykey bezeichnet, wie fremdschlüssel oder unique keys im namen schon kenntlich macht, etc. eine gut durchdachte namensgebung bei -> allen <- objekten und attributen einer datenbank, also auch indexe, constraints, etc. wir dir später sehr, sehr nützlich sein.

und zu guter letzt solltest du auch ein SQL script mit DDL befehlen erstellen, dass dir die alle objekte der datenbank erzeugt. dies ist allein schon hilfreich, um eine testumgebung neben der produktiv datenbank aufzubauen. meistens benöigt man noch ein zweites SQL script mit den initialisierungsdaten, sprich den DML befehlen. selbst wenn eine datenbank  ganz frisch online geht, ist sie selten in allen tabellen ganz "nackt".

das alles kann einem sehr helfen, bei der entwicklung einer datenbank. aber die richtigen entitäten mit den richtigen attributen zu entwickeln und sie dann noch sinnvoll in beziehung miteinander zu setzen, das ist eine kunst für sich.

Ilja