[SQL allgemein] Normalisierung oder NULL?

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

  • [SQL allgemein] Normalisierung oder NULL?

    Hallo SQL-Profis

    Ich bin ein ERD für eine Applikation am designen, die u.a. zum Speichern von Software und deren Speicher- / Lagerorten dient.
    Gelagert oder gespeichert werden kann die Software (im Moment) nur an folgenden 3 Orten:
    -Link (lokal oder Internet)
    -in einer Box, in welcher sich die CDs durchnummeriert befinden
    -verschiedenes (wo man z.B. als Kommentar angeben kann "im weissen Schrank, 3. Regal")

    Ich habe mal 2 Möglichkeiten designt (sind angehängt), welche mich aber etwas in ein Dilemma bringen:
    Möglichkeit 1 ist sicher performancemässig ein Vorteil, Möglichkeit 2 ist aber schön normalisiert. (In der Schule lernen wir, bedingungslos zu normalisieren, von der Praxis her weiss ich aber dass dem nicht so ist ^^)

    Nun wäre ich sehr froh um Vorschläge, Verbesserungen, usw. Ihr dürft euch auch gerne über meine Designs auslassen Das Ziel ist es ja, aus der Sache zu lernen.

    Danke im Voraus und Gruss!
    Onyx
    Angehängte Dateien

  • #2
    Das Problem ist, dass Software ziemlich schnell altern, daher weiss ich nicht, ob es sinnvoll ist, so 'ne Verwaltung zu erstellen . Außerdem in einer gut geführten Firma legt man alle aktuelle Software sowieso als ISO-Image im Netzwerk ab, so dass sie immer sofort zugriffsbereit sind. Also wir brauchen solche Verwaltungssoftware definitiv nicht

    Kommentar


    • #3
      Nun, bei uns besteht definitiv Bedarf nach einer solchen Software Es existieren x-hunderte CDs für die gesamte Firma, und um da noch den Überblick zu bewahren braucht es mittlerweile mehr als unser Erinnerungsvermögen ^^
      Zudem bin ich Lehrling, also eine ideale Gelegenheit für ein Lehrlingsprojekt

      Bleiben wir aber beim ERD, und lassen die Diskussion über den Sinn diese Projekts beiseite ^^

      Besten Gruss
      Onyx

      Kommentar


      • #4
        Erstmal mit der normalisierten Datenbank arbeiten, gezielt optimiert wird später.

        Kommentar


        • #5
          Meinst du?
          Das ist halt genau mein Dilemma Es ist zwar ein Lernprojekt, aber wäre es für den Kunden wären das (grobe Schätzung) 0.5h neue DB Lösung designen, 1h neue DB-Lösung implementieren, 2h Daten mergen, sowie Korrespondenzen + Testing, alles zu einem Stundenansatz von Fr. 200.- (€ 130) gibt 'n hübsches Sümmchen dafür, dass ich anfangs fehlerhaft designed habe...

          Wenn die Wahrscheinlichkeit da ist, dass in einem Jahr die Abfrage aller Daten in der normalisierten Lösung bereits 1 Sekunde länger dauern könnte als die performante, warum sollte man da die normalisierte nehmen?
          Würd mich interessieren, ob Desasters Statement generell zutrifft oder sich da die Meinungen stark teilen

          Gruss, danke für die Antworten
          Onyx

          Kommentar


          • #6
            Wenn du weißt (damit meine ich 100%tig, 99,9999999% ist nicht genug!), dass es NIEMALS weitere Orte gibt, an denen die Software lagert, außer diesen dreien, würde ich die erste Variante nutzen.
            Wenn du dir unsicher bist, nimm die zweite Variante. Du kannst noch eine Typ-Spalte in der Tabelle "Software" machen, und dann genau auf die Tabelle joinen, wo die Software zu finden ist. Deutlich schlechter ist die Variante dann nicht.

            Prinzipiell ist der Weg: Erst normalisiert, dann optimieren; übrigens in der Tat der bessere. Die Optimierungen fallen den guten Leuten allerdings dann beim Programmieren der Applikation auf, und werden dann gleich umgesetzt, sodass das in praktischer 0-Zeit geschieht.

            Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

            bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
            Wie man Fragen richtig stellt

            Kommentar


            • #7
              Normalisieren kann man auch übertreiben...

              Wenn du weißt, was du am ende für Daten brauchst, baust du Dir das Schema.
              In Deinem beispiel wären 3 Dinge interessant (für mich)
              1. Der Datenträger
              2. Welche Software ist auf dem Datenträger
              3. Wo ist der Datenträger

              Also hätte ich eine Tabelle Datenträger, eine mit Software, und eine Location (wobei man hier noch unterteilen könnte in regale und Kisten , sofern du ds Ding mal an Amazon verkaufen willst sogar noch weiter)

              Grundsätzlich ist PHP-Desaster´s Gedanke aber richtig.

              Kommentar


              • #8
                ...abgeschlossen

                Danke für eure Tipps

                Stimmt, die Lösungen haben alle was. Ich habe jetzt mal weitgehend normalisiert. (Und den Thread in die Favs getan, für weitere Fälle dieser Art )

                Also vielen Dank!
                Gruss
                Onyx

                Kommentar

                Lädt...
                X