Ankündigung

Einklappen
Keine Ankündigung bisher.

Datenbank Tabelle mit ca. 400 Spalten

Einklappen

Neue Werbung 2019

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

  • Datenbank Tabelle mit ca. 400 Spalten

    Hallo,

    ich habe in einer Datenbank eine Tabelle mit ca. 400 Spalten. Alle 400 Werte werden überwiegend gleichzeitig aufgerufen.
    Sehr selten werden einzelne Werte benötigt.
    Es gibt keine Probleme. Ich habe aber Bedenken, dass irgendwann Probleme entstehen könnten.
    Sollte ich die Tabelle trennen? Was meint Ihr?

  • #2
    Ja, du solltest die Tabelle normalisieren.

    Ich würde gerne den Use Case sehen wo du eine Tabelle mit 400 Spalten brauchst und davon noch alles gleichzeitig.

    Genaueres kann man natürlich erst sagen wenn man die Tabelle sieht.

    Kommentar


    • #3
      Hallo Tropi,

      danke für deine Antwort. Ich persönlich hatte noch nie so eine große Tabelle und tendiere auch zur Normalisierung.

      Eigentlich ist der Use Case einfach darzustellen. Aber ich beschreibe ihn Mal hier:

      Das System ähnelt einer Umfrage. In dieser Tabelle sind nur Daten vorhanden, die nur im Zusammenhang bearbeitet bzw. Ausgegeben werden.
      Alle 400 Werte werden vom Benutzer in einer Eingabemaske eingegeben bzw. angeklickt (Ja/Nein)
      Bei der Ausgabe muss erscheinen was eingegeben bzw. angeklickt wurde (logisch).
      Das Ergebnis wird mit allen Werten als PDF ausgegeben.
      Der Benutzer hat aber die Möglichkeit, nach der Speicherung, einmalig seine Eingaben zu bearbeiten.
      Es gibt noch eine Suchfunktion. Hierbei kann man nach bestimmten Werten suchen und alle Benutzer ausgeben lassen, die das gesuchte Wert gewählt haben.

      Eins muss noch vermerken: Natürlich sind in dieser Tabelle keine persönlichen Daten der Benutzer oder andere für das System notwendige Daten vorhanden. Für diese gibt es unterschiedliche Tabellen.

      Kommentar


      • #4
        um eine Umfrage darzustellen brauchst du ~3 Spalten.
        Frage, Antwort, Antwortender_id

        Kommentar


        • #5
          Sehe das ähnlich wie ChromOxid. So wie du das schilderst, sind die Spalten vermutlich auch durchnummeriert (für die einzelnen Fragen), was praktisch immer eine schlechte Idee ist.
          Was wenn du plötzliche eine Umfrage mit 600 Werten haben willst? -> Du musst 200 neue Spalten erstellen.
          Was wenn du eine Umfrage mit nur 50 Werten haben willst? -> 350 Werte pro Zeile sind NULL-Werte.
          Das könnte man mit Normalisierung alles vermeiden.

          Kommentar


          • #6
            Zitat von ChromOxid Beitrag anzeigen
            um eine Umfrage darzustellen brauchst du ~3 Spalten.
            Frage, Antwort, Antwortender_id
            Einspruch Euer Ehren:

            Frage_id, Antwort, Antwortender_id....

            Kommentar


            • #7
              tufanum Generelle Faustregel: Wenn du Spalten (oder Variablen) nummerierst, oder zur Laufzeit in der DB Spalten ergänzen musst (bzw. zur Laufzeit das DB-Design verändern), dann ist das fast immer ein Zeichen auf einen Designfehler. Spätestens dann solltest du nochmals ganz scharf nachdenken was du da machst.
              The string "()()" is not palindrom but the String "())(" is.

              Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
              PHP.de Wissenssammlung | Kein Support per PN

              Kommentar


              • #8
                Danke für eure Antworten. Diese waren sehr hilfreich.
                Die Datenbank existierte bereits. Ich habe sie so übernommen.
                Durchnummeriert sind die Fragen nicht. Für jede Frage wurde eine Spalte erstellt. Deshalb auch 400 ca. Spalten.
                Der User muss bei fast über 80% der Fragen einen Text eingeben. Zur Laufzeit müssen die Spalten nicht ergänzt oder gelöscht werden.
                Ich glaube, ich werde eine neue Datenbank anlegen. Das erscheint mir sinnvoller zu sein. Dann sehe ich auch ob das Sinn macht?

                Wünsche euch allen ein schönes Wochenende.

                Kommentar


                • #9
                  Zitat von kaminbausatz Beitrag anzeigen
                  Einspruch Euer Ehren:
                  Frage_id, Antwort, Antwortender_id....
                  Einspruch würde ich auch erheben und unterstreichen bzw. verstärken.
                  Die 3 Spalten, meinetwegen, das ist ein Anfang, aber das reicht auch nicht sehr weit. Natürlich nicht, weil 400 einfach nicht in 3 reingeht.

                  Zunächst
                  Mein Eindruck aus den Punkten des TE: Es ist eine statische Anwendung. Der TE hat nicht mal ein Problem, er fürchtet nur eins, nicht mal klar ob mehr technisch oder mehr logisch (ja, könnte welche geben, ist aber alles im Konjunktiv)

                  Einwände wie
                  "Was machst Du, wenn es nur 150 Fragen sind oder wenn es 600 sind?"
                  Und die vorgeschlagene Normalisierung mit simplen 3 Spalten vorzunehmen, halte ich doch für eine starke Verkürzung der notwendigen Maßnahmen bzw. ein unzureichende Begründung solcher.

                  Ich habe vor ca 2-3 Jahren ein dynamisches Fragensystem für Android Tablet entworfen. Es erlaubt, beliebige Fragenkataloge zu erstellen, ist also dynamisch was Fragenanzahl angeht (allerdings mit anderen Einschränkungen, s.u.).

                  Sobald die Felder nicht mehr statisch sind, wird auch nicht mehr Feld für Feld spezifisch das UI umgesetzt. Dynamische Fragen sind vielleicht nicht alle einfach per Text beantwortet, sondern auch Datumswerte, Zahlen, Fließkommazahlen, n aus m ankreuzen, Bereiche, etc. pp.
                  Kann man erstmal dynamisch Fragen stellen, kommt also als nächstes die ein oder andere Typvariante, dann kommen Bereichsprüfungen, dann kommen abhängige Fragen, Antworthinwise, Reihenfolgen usw usf.
                  Dann kommt noch jegliche Form von Reporting, Darstellung von Ergebnissen usw., wobei nicht unbedingt stumpfe, lange Listen gefragt sind.
                  Alles hängt letztlich an definierten Antworttypen, die allein Vorgaben für UI Gestaltung und Verhalten geben, unabhängig von einer konkreten Frage.
                  Die Antworttypen müssen dann generisch abgearbeitet werden, Verarbeitung und Darstellung.

                  Die bloße Datenmodellnormalisierung ist also weniger als die halbe Wahrheit.

                  Nebenbei, nur weil es 400 Felder sind, bedeutet das nicht automatisch, dass diese denormalisiert vorliegen. Außerdem ist Normalisierung in der Praxis keine Schwarz/Weiß Frage. 90, oder 95 oder 98 % normalisiert wäre m.E. viel für z.B 400 Spalten in einem fertig entwickelten System Fragesystem.

                  Was will ich damit sagen?
                  Mal eben normalisieren, die Tabelle "trennen", alles auf 3 Spalten umbauen klingt viel harmloser als es ist.
                  Es geht über "normale" Normalisierungsfragen hinaus, es geht um generische Modellierung und Implementierung.
                  Das ist nichts schlimmes, aber

                  bevor man soetwas beginnt, sollten
                  erstens mehrere gute Gründe vorliegen (nicht nur Sorgen, es könnte ja mal was sein) und
                  zweitens sehr genau festgelegt sein, wie das Zielsystem aussehen soll und wie das Zeit/Geldbudget dafür aussieht.
                  Gilt besonders, wenn ein fertiges, funktionierendes System vorhanden ist und umgebaut werden soll.

                  Kommentar


                  • #10
                    Perry Staltic

                    Danke für deine Antwort.
                    Mir ging es eigentlich darum ob es Sinn macht, die bestehende Tabelle zu Trennen. Ich hätte nach Themen trennen können (wären 8 Themen). Aber wie ich schon oben geschrieben habe, werden die Werte nur in Zusammenhang aufgerufen und verarbeitet.

                    Aus diesem Grund => Wie heißt es so schön: Never change a running system (Das scheint Sinnvoller zu sein)

                    Kommentar


                    • #11
                      Perry Staltic

                      Mein Einspruch bezog sich darauf, dass die 3 Spalten mit "Frage, Antwort, Antwortender_id" benannt wurden.Ich denke, dass es keinen Sinnn macht, die Fragen mit in diese Tabelle aufzunehmen, sondern nur die Fragen_id.

                      Ansonsten muss ich den Vorrednern schon recht geben. Ein Tabelle mit 400 Spalten ist vollkommen daneben und widerspricht im Grunde allem was wir bisher über Datenbankdesign gelernt haben. Je nach Feldgröße erreicht man hierbei auch schnell die Grenzen von bspw. MySQL -- InnoDB.

                      Es würde ja auch keiner bspw. eine Tabelle namens Bestellungen für einen Miniwebshop mit 400 Artikeln wie folgt aufbauen:
                      Kunde_id Artikel1 Artikel2 Artikel3..-399 Artikel400
                      1001 10 11
                      1002 12 1

                      Kommentar


                      • #12
                        Zitat von kaminbausatz Beitrag anzeigen
                        Perry Staltic

                        Ein Tabelle mit 400 Spalten ist vollkommen daneben und widerspricht im Grunde allem was wir bisher über Datenbankdesign gelernt haben.
                        Ich muß jetzt an einen Kunden denken, der "Old School Style" auf jede Spalte einen Index gesetzt hatte... wenn dann das noch zusammenkommt
                        PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                        Kommentar


                        • #13
                          tufanum
                          Kann man so sehen, aber von "never" habe ich auch nichts geschrieben. Ich bin der Meinung man muss es gut abwägen und in Deinem Fall, aber auch vielen anderen den wirklichen Umstellungsaufwand bedenken.
                          Eine Trennung z.B. nach Themen ändert allenfalls mögliche technische Probleme, nichts anderes.

                          kaminbausatz
                          Klar 400 Spalten ist eine Hausnummer, da müffelt es schon ziemlich. Aber ich bleibe dabei, allein die Anzahl der Spalten sagt nichts über Normalisierung.
                          Auch klar, ich habe lediglich deinen Einspruch an sich aufgegriffen, nicht Deine Lösung.

                          Ich kann ohne Probleme aus einer Anschrifttabelle 20 Fragen formulieren:
                          Wie lautet Ihr Vorname
                          Wie lautet Ihr Mittelname
                          Wie lautet Ihr Nachname
                          Wie lautet Ihr Geschlecht
                          usw usf
                          Ist ein Adressdatensatz deswegen und weil es weniger als 400 Fragen damit nicht normalisiert?
                          Dein Gegenbeispiel zur Normalisierung ist richtig, trifft aber nicht den Fall des TE. Dort werden 400 Fragen / Antworten erhoben die alle(!) gleichwertig nebeneinander stehen und als Datum erforderlich sind.

                          akretschmer
                          Man kann bei genügend großen Systemen immer einen Aspekt rauspicken, der suboptimal umgesetzt ist. Notfalls kann man sich auch viele ungünstige Konstellationen kombiniert vorstellen. Und es geht immer irgendwie noch besser.

                          All das ändert nichts an meiner Kritik zu den Antworten hier. Eine generische Datenhaltung, die mit einem auf den ersten Blick verblüffend einfachen 3 Spalten Datenmodell erreicht wird, erfordert viel Aufwand an ganz anderen Stellen. Das gilt es zu bedenken, nicht mehr und nicht weniger.
                          Ich habe auch gar nichts gegen Normalisierung, Normalisierung ist der natürliche Freund des Entwicklers. Es kommt halt auf die Umstände an (und ob überhaupt eine Denormalisierung vorliegt)
                          Die sicher gut gemeinten Ratschläge scheinen mir also einfach etwas leichtfertig.

                          Ich würde wahrscheinlich selber nie ein solches System neu bauen, wie es der TE in den Fingern hat. Wenn ich mich aber um ein solches fertiges System kümmern müsste, wäre eine Trennung in 5 oder 20 Tabellen sicher nicht meine Wahl, ein Umbau zu einer generischenn Lösung nur entsprechend Budget und neuen Anforderungen.

                          Kommentar


                          • #14
                            Der Grund warum mein Ratschlag so einfach gehalten ist, ist einfach Erfahrung mit den Fragen hier. Ob etwas normalisiert gespeichert wird oder nicht spielt eine untergeordnete Rolle, entscheidend ist dabei ob es Absicht ist oder nicht. Ganz nach dem Motto "Man muss die Regeln kennen um sie zu brechen". Normalisierung muss nicht immer sein, man muss nur wissen wann und warum nicht.

                            Selbiges gilt für 400 Spalten: Entweder man weiß genau warum man so viele Spalten hat (und braucht), oder man kann das Design verbessern. Zufällig landet man nicht bei 400 Spalten.

                            Kommentar

                            Lädt...
                            X