Ankündigung

Einklappen
Keine Ankündigung bisher.

1 oder 2 Tabellen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • 1 oder 2 Tabellen

    Hallo zusammen,

    ich stehe vor folgender Frage:

    ich habe eine Tabelle mit Spezialfahrzeugen. In dieser Tabelle gibt es diverse Spalten, die auf die Spezialfahrzeuge bezogen sind. Jetzt sollen weitere Fahrzeuge aufgenommen werden, wo die meisten Spalten von den Spezialfahrzeugen nicht zu passen. Es kommen andere Spalten in Frage. Macht es mehr Sinn, die Fahrzeuge in 2 verschiedene Tabellen zu packen oder in eine und bei den Fahrzeugen sind viele Spalten NULL, da diese gar nicht benötigt werden?

    Hintergrund der Frage ist, dass die ID´s mit anderen Tabellen verknüpft sind (Dokumente, Fotos ...). Wenn ich in einer neuen Tabelle wieder mit ID 1 anfange, wären die Dokumente falsch verknüpft oder ich müsste dann für normale fahrzeuge auch wieder eigene Tabellen für Fotos, Dokumente usw. erstellen und füllen.


  • #2
    Moin,

    pack die Fahrzeuge alle in eine Tabelle, die Null-Spalten tun nicht weh.

    Je nach Art der zusätzlichen Spalten kann man darüber nachdenken diese in eine andere Tabelle auszulagern, dafür müsste man aber mehr über das Thema wissen.
    Relax, you're doing fine.
    RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

    Kommentar


    • #3
      Zitat von truemaster Beitrag anzeigen
      Hallo zusammen,

      ich stehe vor folgender Frage:

      ich habe eine Tabelle mit Spezialfahrzeugen. In dieser Tabelle gibt es diverse Spalten, die auf die Spezialfahrzeuge bezogen sind. Jetzt sollen weitere Fahrzeuge aufgenommen werden, wo die meisten Spalten von den Spezialfahrzeugen nicht zu passen. Es kommen andere Spalten in Frage. Macht es mehr Sinn, die Fahrzeuge in 2 verschiedene Tabellen zu packen oder in eine und bei den Fahrzeugen sind viele Spalten NULL, da diese gar nicht benötigt werden?
      Klingt für mich so, daß da im Laufe der Zeit immer wieder weitere Spalten dazukommen. Das sollte man tunlichst vermeiden. Die Alternativen sind EAV-Lösungen oder aber die Eigenschaften in z.B. Key-Value oder JSON-Feldern abzulegen. Das sind die üblichen Lösungen.

      Hintergrund der Frage ist, dass die ID´s mit anderen Tabellen verknüpft sind (Dokumente, Fotos ...). Wenn ich in einer neuen Tabelle wieder mit ID 1 anfange, wären die Dokumente falsch verknüpft oder ich müsste dann für normale fahrzeuge auch wieder eigene Tabellen für Fotos, Dokumente usw. erstellen und füllen.
      Gut, das wäre mit Sequenzen machbar.
      PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

      Kommentar


      • #4
        Es würde Sinn machen, die Datenbank zu normalisieren.

        Tabelle "Fahrzeuge" enthält idealerweise nur noch die ID und eine Bezeichnung für ein Fahrzeug.
        Eigenschaften werden in einer gesonderten Tabellen abgelegt, die Verbindung von "Fahrzeug" und "Eigenschaft" erfolgt über eine dritte Tabelle.
        Ganz streng genommen, müsste ein Datensatz in dieser Zwischentabelle einen eigenen PK bekommen, mit dem man dann (unter Zuhilfenahme einer 4. Tabelle), die Eigenschaftswerte abspeichern würde.
        Es "geht" aber auch, das der Eigenschaftswert mit in die die Zwischentabelle kommt (den PK kann man sich dann sparen).

        Fahrzeug: ID, name
        Eigenschaft: ID, name
        FahrzeugEigenschaften: ID_fahrzeug, ID_eigenschaft, value


        Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

        Kommentar


        • #5
          Hier kann man überlegen, ob man "ordentlich normalisiert", mal in NoSQL badet oder stumpf Key Value macht.

          Für eine Normalisierung spricht alles, was seit ihrer Erfindung für Normalisierung spricht.
          Für NoSQL spricht die Mischung aus "alles geht", schlampiger Eleganz und schneller Umsetzung
          für KeyValue spricht eine absolut unbegrenzte, flexible und gleichzeitig formalisierte Darstellung und Verarbeitung von beliebigen Eigenschaften.

          Es ist wie mit allen Produkten oder produktartigen Tabellen. Wer konnte vor ein paar Jahren ahnen, dass man bald keine Spalte mehr für Diesel braucht und das Autos heutzutage 1 bis N Motoren haben und die dann auch noch unterschiedliche Typen. Leistung ist auf einmal Systemleistung und Verbrauch ist, .. .. . arghs

          Also, ich würde mal mit JSON probieren. Man kann reinschreiben, was man will und der einzige, der es verstehen muss ist die eigene Anwendung. Das bietet natürlich Spielraum für Chaos. Also schön aufpassen und mitschreiben, was man alles erfindet. Idealerweise plant und schreibt man es erst auf und implementiert dann.

          Aber wenn morgen der Andi eine neue, besteuerte Idee hat, JSON kann das.

          Kommentar


          • #6
            Zitat von Perry Staltic Beitrag anzeigen
            Es ist wie mit allen Produkten oder produktartigen Tabellen. Wer konnte vor ein paar Jahren ahnen, dass man bald keine Spalte mehr für Diesel braucht und das Autos heutzutage 1 bis N Motoren haben und die dann auch noch unterschiedliche Typen. Leistung ist auf einmal Systemleistung und Verbrauch ist, .. .. . arghs
            Allerdings ist eine Datenstruktur auch nicht in Stein gemeißelt, sondern kann angepasst werden.

            Denn das Datenmodell muss schließlich auch angepasst werden, oder hättest du eine Klasse "Auto" vor 20 Jahren mit einem Array für Motoren versehen, statt einem einzigen Property?

            Kommentar


            • #7
              Natürlich kann eine Datenstruktur angepasst werden. Aber es ist so, je komplexer sie bereits ist, desto mehr Bedenken und konkurrierende Anforderungen (Last) gibt es, wie weit wird etwas ausmodelliert. Außerdem kommt es beim Deploy dann eben u.U. zu Ausfallzeiten und (temporären) Inkompatibilitäten. All das, weswegen NoSQL erfunden wurde.

              Ich bin ein großer Freund von ordentlichen Datenmodellen. Trotzdem dürfen es gerne auch mal ein paar Spalten mehr sein, die nur sporadisch befüllt werden, für Exoten halt- wie schon von VPh vorgeschlagen. Aber da geht dann irgendwann das Problem los. Die Sachbearbeiter sind fantasievoll und nutzen solche Felder anders als vorgesehen. Dann gibt's extra Schleifen bei der Eingabeprüfung usw usw.
              Und ehrlich, DB Änderungen sind in der Handhabung steifer als ein JSON Feld mit neuen Properties. Nicht jedes RDBMS kompiliert mal eben automatisch alle abhängigen Objekte der geänderten Tabelle neu, wie es Oracle DB bspw. macht.

              Aber mein Punkt ist letztlich noch etwas anders.
              Ich würde bei der Frage unterscheiden zwischen beinharter Business Logic und eben dem Rest. Für manche Dinge geht's halt auch ne Nummer kleiner, im Sinne von weniger Aufwand, Platz sparend ist JSON ja nicht unbedingt. Der Dokumentcharakter vieler Informationen spielt auch ne Rolle. Es muss nicht alles super kompakt und im indizierten Zugriff sein.

              Kommentar


              • #8
                Zitat von Perry Staltic Beitrag anzeigen
                Natürlich kann eine Datenstruktur angepasst werden. Aber es ist so, je komplexer sie bereits ist, desto mehr Bedenken und konkurrierende Anforderungen (Last) gibt es, wie weit wird etwas ausmodelliert. Außerdem kommt es beim Deploy dann eben u.U. zu Ausfallzeiten und (temporären) Inkompatibilitäten. All das, weswegen NoSQL erfunden wurde.
                Das ist doch bei NoSQL auch so. Beim angesprochenen Auto, wenn man das Motor-Property durch ein Array tauscht müssen ja auch die Bestandsdaten angepasst werden. Oder man jongliert ewig mit zwei Versionen vom Modell herum, einmal eins mit und einmal eins ohne Array. Und das wird dann in Zukunft auch immer komplexer, je mehr Varianten von einem Modell man in der Software unterstützen will.

                Icn sehe da ehrlich gesagt keine Vorteile in NoSQL. NoSQL macht IMHO bei wirklich dynamischen Datenstrukturen sind und nicht bei statischen Strukturen, die sich alle heilige Zeiten mal ändern könnten.

                Und Ausfallzeiten hat ma immer beim Deployen. Deswegen macht man das auch ja auch in Wartungsfenstern und nicht mitten im Hochbetrieb.

                Kommentar


                • #9
                  Zitat von hellbringer Beitrag anzeigen

                  Und Ausfallzeiten hat ma immer beim Deployen. Deswegen macht man das auch ja auch in Wartungsfenstern und nicht mitten im Hochbetrieb.
                  Dann hast du wohl noch nie Software kennengelernt, wo es um Menschenleben oder Millionenbeträge geht, die eine vier oder fünf Neuner Verfügbarkeit verlangen.
                  Da ist nichts mit Downtime beim Deployen.

                  Kommentar


                  • #10
                    Zitat von Meister1900 Beitrag anzeigen

                    Dann hast du wohl noch nie Software kennengelernt, wo es um Menschenleben oder Millionenbeträge geht, die eine vier oder fünf Neuner Verfügbarkeit verlangen.
                    Da ist nichts mit Downtime beim Deployen.
                    Verstehe ich alles irgendwie nicht. Normalerweise gibt es ein produktives System. Wenn das verändert wird, passiert es lokal. Dann testet man es, zuerst lokal, dann indem man es auf einem Pfad, der niemandem bekannt ist, veröffentlicht. Wenn das alles funktioniert hat, wird die neue Version produktiv gesetzt und sofort von Testusern getestet. Die Auswertung dieser Tests entscheidet darüber, ob sofort wieder die alte Version installiert wird oder die neue Version aktiv bleibt.

                    Wartungsfenster? Habe nie verstanden, wofür man die braucht.

                    Kommentar


                    • #11
                      Zitat von Meister1900 Beitrag anzeigen
                      Dann hast du wohl noch nie Software kennengelernt, wo es um Menschenleben oder Millionenbeträge geht, die eine vier oder fünf Neuner Verfügbarkeit verlangen.
                      Da ist nichts mit Downtime beim Deployen.
                      Diese verwenden doch hoffentlich kein PHP. Davon abgesehen ein komisches Argument. Weil es bei 0,0001% der Software-Produkte relevant ist, müssen 99,9999% alle anderen Software-Produkte auch so gemacht werden? Oder worauf willst du hinaus? Außerdem sind solche HA-Lösungen üblicherweise mehrfach redundant ausgeführt. Da ist es nicht so, dass alles steht, nur weil eine einzige Datenbank offline ist.

                      Zitat von marie123 Beitrag anzeigen
                      Wartungsfenster? Habe nie verstanden, wofür man die braucht.
                      Beim Deployment von neuer Software gibt es üblicherweise eine Downtime. Deswegen sollten Deployments so geplant werden, dass sie dann stattfinden, wenn die Software am wenigsten verwendet wird. Das mag bei popeligen PHP-Scripts, die aus 3 Dateien bestehen, nicht wirklich relevant sein. Aber bei größeren Anwendungen mit komplexen Migrationen kann so ein Deployment schon mal mehrere Minuten, im Extremfall sogar Stunden dauern.

                      Deswegen planen verantwortungsvolle Firmen bzw. Entwickler vernünftige Wartungsfenster und geben sie auch den betroffenen Usern bzw. Clients bekannt, damit sich diese darauf einstellen können und es zu keinen bösen Überraschungen kommt.

                      Kommentar


                      • #12
                        Zitat von marie123 Beitrag anzeigen
                        Wenn das alles funktioniert hat, wird die neue Version produktiv gesetzt und sofort von Testusern getestet. Die Auswertung dieser Tests entscheidet darüber, ob sofort wieder die alte Version installiert wird oder die neue Version aktiv bleibt.
                        Genau diese Phase ist doch das Wartungsfenster.
                        Während wir die Produktivumgebung noch einmal zur Abnahme testen [lassen], sind dort die normalen Sachbearbeiter vorerst nicht unterwegs; damit für diese im Falle eines Rollbacks keine unnötige Arbeit entsteht.
                        Relax, you're doing fine.
                        RTFM | php.de Wissenssammlung | Datenbankindizes | Dateien in der DB?

                        Kommentar


                        • #13
                          Zitat von Meister1900 Beitrag anzeigen

                          Dann hast du wohl noch nie Software kennengelernt, wo es um Menschenleben oder Millionenbeträge geht, die eine vier oder fünf Neuner Verfügbarkeit verlangen.
                          Da ist nichts mit Downtime beim Deployen.
                          bei 99.99 % hab ich ne schlappe stunde pro jahr, bei 5 immerhin noch 5 minuten...
                          Ich weiss nicht was Du für Software meinst - ein hint wäre nicht schlecht - und ob diese überhaupt sinnvoll in php zu realisieren ist;

                          flugsicherheit jedenfalls in den 80ern noch eine paradebeispiel für stabile realtime anwendungen, kennt spätestens seit den neunzigern minutenlange
                          black mirrors, wie man anhand verschiedener unglücke feststelllen konnte.



                          Kommentar


                          • #14
                            Ich komme aus der Finanzwelt und kenne einige Anwendungen, bei denen es keine Downtime geben darf (z.B. für den Betrieb von Geldautomaten). Wartungsfenster gibt es hier natürlich auch, aber das ist nicht mit einer Downtime gleichzusetzen.
                            Hier arbeitet man entweder mit mehreren Datenbanken mit meist eigenen Synchronisierungsprozessen oder z.B. mit ISO8583 Nachrichten, die in BLOBs gespeichert werden, damit man an die Datenbankstruktur möglichst nicht mehr ran muss.
                            Diese Anwendungen sind aber in der Tat nicht in PHP geschrieben, aber hier ging es ja auch allgemein um Datenbanken.
                            Glaube auch, dass die Prozentzahlen, die hellbringer jetzt auf die Anzahl der Anwendungen (statt auf die Verfügbarkeit) bezieht zu gering sind. 3 Branchen wurden ja hier schon genannt.
                            Und generell, ist es nicht ein Qualitätsmerkmal für eine Software, dass diese ohne großartige Downtimes auskommt? Hochverfügbarkeit muss nicht nur Aufgabe der Infrastruktur sein, man sollte sich auch als Entwickler darum Gedanken machen.

                            Kommentar


                            • #15
                              Zitat von Meister1900 Beitrag anzeigen
                              Ich komme aus der Finanzwelt und kenne einige Anwendungen, bei denen es keine Downtime geben darf (z.B. für den Betrieb von Geldautomaten). Wartungsfenster gibt es hier natürlich auch, aber das ist nicht mit einer Downtime gleichzusetzen.
                              Hier arbeitet man entweder mit mehreren Datenbanken mit meist eigenen Synchronisierungsprozessen oder z.B. mit ISO8583 Nachrichten, die in BLOBs gespeichert werden, damit man an die Datenbankstruktur möglichst nicht mehr ran muss.
                              Diese Anwendungen sind aber in der Tat nicht in PHP geschrieben, aber hier ging es ja auch allgemein um Datenbanken.
                              Glaube auch, dass die Prozentzahlen, die hellbringer jetzt auf die Anzahl der Anwendungen (statt auf die Verfügbarkeit) bezieht zu gering sind. 3 Branchen wurden ja hier schon genannt.
                              Und generell, ist es nicht ein Qualitätsmerkmal für eine Software, dass diese ohne großartige Downtimes auskommt? Hochverfügbarkeit muss nicht nur Aufgabe der Infrastruktur sein, man sollte sich auch als Entwickler darum Gedanken machen.
                              Man muss auch Nutzen und Kosten gegenüber stellen. Downtimes sind in der realen Welt überall allgegenwertig. Zum Beispiel als meine Bank ihr Online-Banking-System upgedated hat, war es einen kompletten Tag offline. Also ein ganzer Tag, an dem hunderttausende Kunden keine Zahlungen tätigen und entgegennehmen konnten.

                              Selbst große Cloud-Dienste wie Microsoft Azure haben Downtimes bzw. zeitweise starke Einschränkungen bei manchen Services. Siehe History:

                              https://status.azure.com/en-us/status/history/

                              Sicher ist das Ziel seine Anwendung so unterbrechungsfrei wie möglich zu betreiben. Aber wo ist das wirklich notwendig? Das ist doch die äußerste Ausnahme.

                              Und wie ich auch erwähnt habe, ist NoSQL auch kein Wunderding, das plötzliche alle Grenzen aufhebt. Es gibt da und dort Probleme. Man sollte die Dinge verwenden, wofür sie gedacht sind. NoSQL für dynamische Datenstrukturen und relationale Datenbanken für statische Datenstrukturen. Es gibt für jedes Problem unterschiedliche Lösungen und keine perfekte Lösung für alle Probleme. In vielen Fällen werden beide Lösungen parallel eingesetzt. Warum sich auf eines beschränken, wenn man die Vorteile von beiden Welten haben kann?

                              Kommentar

                              Lädt...
                              X