Eigene Datenbank oder Tabellen mit Präfix?
-
Ich entwickle für meinen neuen Arbeitgeber eine Anwendung. Die Daten der Anwendung sollen in einer SQL-Datenbank abgelegt werden. Dazu gehören Geschichten wie User-Logins und Benutzerprofile. Die Anwendung und die Daten sind komplett eigenständig, es gibt keine Abhängigkeiten zu anderen Datenbanken.
Nun habe ich dafür ein Datenmodell entworfen und dabei alles so benannt, als wäre es eine eigenständige Datenbank. Da die Anwendung komplett eigenständig laufen soll, scheint mir das eine saubere Lösung zu sein.
Beim Besprechen meines Fortschritts hat mich dann ein anderer Entwickler aufgefordert, die Tabellen mit einem Präfix zu versehen, damit klar ist, zu welcher Anwendung die Daten gehören. Meinen Einwand, dass es eine eigene Datenbank werden soll, hat er weggebügelt und gemeint, dass das in die bestehende Datenbank kommen soll, in der auch die ganzen anderen Anwendungen ihren Kram ablegen. Meine Frage nach dem Warum wurde mit "Das macht man bei Webanwendung einfach so. Sonst gibt es Probleme mit den Connections" beantwortet.
Ich habe nicht genug Erfahrung was DB-Anwendungen angeht, und kann deshalb außer "Sauberkeit" und "eigener Namespace" keine Argumente gegen "das macht man halt so" vorbringen.
Was haltet ihr davon? Ist es wirklich richtig, Daten, die nichts miteinander zu tun haben, in eine Datenbank zu schmeißen? Welche Argumente könnte ich vorbringen, um die Leute umzustimmen?
-
Ich würde schon auf Grund der Rechtevergabe zumindest zu einem eigenen Schema raten. Kommt natürlich auch auf das verwendete DB-System an, aber die Präfix-Methode klingt mir doch sehr nach "wir sind auf einem shared host und haben einen Tarif mit nur einer DB"... mag sein, dass sich die Möglichkeit eines Präfix deshalb bei vielen PHP-Web-Anwendungen ala phpBB, etc. durchgesetzt hat. Üblich auf großen System ist es jedenfalls nicht.
MfG SideWinder
-
SideWinder schrieb:
Ich würde schon auf Grund der Rechtevergabe zumindest zu einem eigenen Schema raten. Kommt natürlich auch auf das verwendete DB-System an, aber die Präfix-Methode klingt mir doch sehr nach "wir sind auf einem shared host und haben einen Tarif mit nur einer DB"...
MySQL und es ist kein Shared Host.
Rechtevergabe... das läuft dann wieder unter "sauber implementiert", was offenbar kein Argument ist, das zieht. Dann heißt es vermutlich "Die anderen Anwendungen machen das auch so, wir machen das schon immer so, und es gab nie ein Problem mit der Rechtevergabe". Ich habe generell nicht den Eindruck, dass ordentliche Rechtevergabe ein Problem ist, mit dem man sich hier befassen möchte.
Wenn es kein Killerargument gegen die Präfixe gibt, mache ich es halt so. Will mich als neuer nicht gleich schon mit dem Rest der Belegschaft anlegen.
-
Nein, es ist nicht üblich Daten die überhaupt nichts miteindner zu tun haben in einer gemeinsamen DB zu haben.
Sinnvoll ist es allerdings dann, wenn es doch Berührungspunkte gibt. Dann ist es einfach praktisch wenn man ohne Verränkungen Abfragen über alle Tabellen machen kann bzw. wenn Transaktionen einfach so über alle Tabellen funktionieren.
Weitere Argumente kann ich dir auch keine liefern. Im Prinzip läuft das schon alles auf "Sauberkeit" hinaus. Bzw. vielleicht noch "Übersichtlichkeit".
Du könntest aber mal nachfragen was genau das für "Probleme mit den Connections" sein sollen die dabei auftreten.
-
Nachdem man mich kürzlich in einem Meeting dafür gelobt hat, dass ich ein Konzept schreibe, und sogar Primär- und Fremdschlüssel(!) in meinem Datenmodell verwende, habe ich mich dafür entschieden, nicht weiter Wert auf sauberes Design oder Nachvollziehbarkeit zu legen. Stattdessen ruhe ich mich auf der Inkompetenz der Kollegen aus, und mache mir lieber einen schönen Lenz. Leicht verdientes Geld.
Trotzdem Danke für das Feedback.
-
dbqp schrieb:
Nachdem man mich kürzlich in einem Meeting dafür gelobt hat, dass ich ein Konzept schreibe, und sogar Primär- und Fremdschlüssel(!) in meinem Datenmodell verwende, habe ich mich dafür entschieden, nicht weiter Wert auf sauberes Design oder Nachvollziehbarkeit zu legen. Stattdessen ruhe ich mich auf der Inkompetenz der Kollegen aus, und mache mir lieber einen schönen Lenz. Leicht verdientes Geld.
Fühlst du dich vollständig wohl dabei? Es wäre meiner Meinung nach schade, wenn du deine Ansprüche nur wegen deiner Kollegen runter schraubst, obwohl du es vom Herzen her gar nicht willst.
-
Da hast du schon recht. Ich mag es, sehr gute Arbeit zu leisten, auf die ich stolz sein kann. Damit fühle ich mich wohl.
Ich mag es aber ehrlich gesagt noch mehr, nur das Mindeste leisten zu müssen, weil die Kollegen und Arbeitgeber den Unterschied zwischen (meiner Vorstellung von) sehr gut und akzeptabel sowieso nicht erkennen. So erledige ich alles auf dem erwarteten Niveau in der halben Zeit und es bleibt mir mehr Zeit für meine eigenen anspruchsvollen Projekte, auf die ich dann stattdessen stolz sein kann.
Ich suche mir meine Schlachten aus, und das hier ist keine, die ich führen möchte.
Der Grund für "Probleme mit den Connections" war übrigens, dass eine Art selbstgestricktes Framework zum Einsatz kommt, in dem mehrere Projekte unter einem gemeinsamen Dach laufen. Dieses Framework übernimmt die Datenbankverbindung für dich, es muss zwingend benutzt werden, und ist nun mal nur für eine einzige Datenbank ausgelegt.
-
dbqp schrieb:
Der Grund für "Probleme mit den Connections" war übrigens, dass eine Art selbstgestricktes Framework zum Einsatz kommt, in dem mehrere Projekte unter einem gemeinsamen Dach laufen. Dieses Framework übernimmt die Datenbankverbindung für dich, es muss zwingend benutzt werden, und ist nun mal nur für eine einzige Datenbank ausgelegt.
Jetzt kann man unterschiedlicher Meinung sein ob es besser ist einfach damit zu leben, oder es nicht besser wäre das Framework mal anzupassen. Was ich aber auf jeden Fall doof finde: Sowas kann der Herr Kollege ja gleich sagen. Also einfach sagen "unser Framework kann nur eine DB" statt nem ominösen, undurchsichtigen "Probleme mit Connections". Dann weiss man wenigstens was Sache ist. Finde ich halt professioneller. Wenn bei uns irgendwas nicht geht, weil wir irgendwo mistigen Code haben der damit nicht klarkommt, dann sag ich das auch so - auch neuen Mitarbeitern. Und schieb nicht irgendwelche seltsamen Aussagen ala "das machen wir nicht weil damit hatten wir mal Probleme" raus.
-
hustbaer schrieb:
Jetzt kann man unterschiedlicher Meinung sein ob es besser ist einfach damit zu leben, oder es nicht besser wäre das Framework mal anzupassen.
Das hätte ich natürlich auch vorgeschlagen, aber "Das macht man halt so" war ernst gemeint, das ist die Überzeugung hier. Das Design ist gut und braucht keine Anpassung oder Verbesserung ist Konsens. Mehrere Datenbanken zu verwenden scheint irgendwie ineffizient oder sonstwie schlecht zu sein.
-
Jo. Doof. Klingt nach einer Firma wo es schwer sein wird viel dazuzulernen. Wenn du nicht stehen bleiben willst wäre es wohl gut demnächst bald mal zu wechseln.
-
hustbaer schrieb:
Und schieb nicht irgendwelche seltsamen Aussagen ala "das machen wir nicht weil damit hatten wir mal Probleme" raus.
Das lässt sich nicht immer vermeiden. Hab ich von Kollegen früher öfter mal gehört und hab mir gedacht Blödsinn, ich probiers einfach mal. Aber nach dem ich jetzt selber ein Senior Developer bin in der Firma, muss ich das leider auch ab und zu auch selber sagen. Bleibt ab und zu nur hängen, da war vor zig Jahren mal was, aber keine Ahnung, was wir genau gemacht haben, und was das Problem war.
dbqp schrieb:
Das hätte ich natürlich auch vorgeschlagen, aber "Das macht man halt so" war ernst gemeint, das ist die Überzeugung hier.
Das kommt drauf an, ob und was zu sagen hast, oder nicht. Und ich denke, wenn man sieht, dass du was leisten kannst, dann wirst du auch was zu sagen haben. Lass dich mit solchen Aussagen nicht abspeisen. Ich hab den Anfang vom Post nicht gelesen. Aber für mich kommts bei sowas drauf an, wie wichtig die Änderung ist, und ob der Aufwand und das Risiko für die Änderung vertretbar sind (und danach siehts mir hier schon aus). Darüber müssen die erfahreneren Kollegen aber mit dir reden. Es kann ja auch sein, dass das schlechte Design einfach schon an sehr vielen Stellen verwendet wird und ein Umbau einfach sehr viel Zeit kostet und die Gefahr besteht, dass man etwas kaputtmacht, was man erst viel später bemerkt. Kann aber auch sein, dass sich das Ganze einfach umbauen lässt. Wenn die Kollegen aber nicht über sowas mit sich reden lassen, würd ich mir schon echt überlegen, obs Sinn macht, da weiterzumachen.
