ER-Modell mit FK sowie Actions

Kampfgummibaerlie

Kampfgummibaerlie

Datenbank-Guru
Beiträge
756
ist es üblich, dass man ER-Modelle konstruiert mit den Beziehungen (Foreign Keys) und entsprechende Aktionen dazuschreibt, wenn nicht der Default-Wert genommen werden soll?

Weil meine Überlegung in der letzten Zeit wäre es, auf meine finanzielle Resourcen zurückzugreifen, um irgendwie einen PG-Modeler zu erwerben, wobei ich mir einerseits absolut nicht sicher bin, wie ich damit arbeiten sollte.

Sollte ich das Ganze zu Beginn, damit ich effektiv mit solchen Modellen arbeite dort fortfahren, wo ich angefangen habe? Sprich auf Miro | The Visual Workspace for Innovation ?

Oder sollte ich zwecks "nicht das falsche anlernen" mit einem professionellen Programm arbeiten?

PGAdmin hat auch ein Tool dabei, um sowas darzustellen, nennt sich "ERD Tool"...

Also, was ich im moment denke und für sinnvoll sehe:
1.: auf Papier anfangen, weil der Mensch angeblich besser lernt durch schreiben / zeichnen
2.: die nötigen Funktionen für zu erstellende Typen erstellen
3.: die nötigen Typen erstellen
4.: das ER-Modell im PGAdmin "zeichnen"...

Was mich bisher daran gehindert hat? Die Tatsache, dass ich kaum produktiv an mir arbeite und meistens einen Tritt/Stoß brauche, damit ich damit anfange, wenn ich aber erst einmal damit angefangen habe, geht es ;)

Auch dies ist eine Kompetenz, die ich mir noch aneignen sollte...
 
Werbung:
Ich denke, das Zeichnen kann helfen, auch mit Bleistift, Lineal usw.
Was das Nette an solchen Tools ist, man zeichnet irgendwas, benutzt tolle Funktionen und Assistenten und bekommt am Ende die Create Statements mit allem Drumunddran. Dann "erlebt" man sozusagen, was so ein Bild bedeutet.
Ob es das Ergebnis das Wunschergebnis ist, versteht man mglw. gar nicht. Bzw. man braucht auch mit einem solchen Tool ein paar Anläufe.

Diese Tools beginnen meist mit einem logischen Modell, also DB unabhängig und generieren Scripte für "beliebige" RDBMS. Gleichzeitig hat man natürlich das Bild, das man auch layouten kann. Tabellen gruppieren (nicht group by ;) ) nach Themen, usw.
Das braucht man eigentlich nicht. Nicht wenn man eine One Man Show ist.
Viele der Features sind interessant für Teams, zu Dokuzwecken (fürs Team), Änderungsverwaltung, Multi DB, ..

Mal ein Modell und bau die Tabellen zu Fuß.
Übertreib nicht gleich. Es reicht mit
Vorhandenen Typen
FK Constraints
Defaults
Werte Constraints

Dazu dann
Views
Trigger (nur bei Bedarf)

Damit kann man viel erreichen.

Wenn's juckt,
dann noch Stored Procedures / Functions
JSON
Arrays
...

Das Wichtige ist Machen und Nutzen, also ein Programm dazu und feststellen, wo es hakt. Ändern, Verbessern, weiter..
 
Ich glaube ich praktiziere schon die ganze Zeit das "Wichtige"...

Ich glaube meine Probleme sind:
1.: Es entwickelt sich nur langsam das Interesse an meinen gelernten Skills, sprich Mtarbeiter und so weiter
2.: Bis in den Sommer war ich der Typ, der irgendwann (ich denke Krankheitsbedingt) einfach alles löscht und von vorne anfangt...

Das von Vorne anfangen hat mich in sofern eigentlich oft weitergebracht im Sinne von "etwas neues erfahren" oder so...
 
Werbung:
Zurück
Oben