9
Frage zu Datenbanklayout (MSSql)
Hallo zusammen,
wir lassen ein Tool schreiben welches Datensätze erstellt und verarbeitet. Die Details würden jetzt etwas zu weit führen aber die programmierer würden die Daten in einem eigenen Serverprogramm speichern. Ich würde die Daten lieber im SQL speichern, bin aber was das Layout angeht gerade etwas überfragt. Folgende Situation:
Ein "Projekt" besteht aus mehreren Datenfeldern (bis zu 3000). Jedes dieser Datenfelder hat selbst nochmal ca. 10 Datenfelder welche hauptsächlich als Strings mit einer Länge von 4-ca. 300 Zeichen vorliegen.
Der Ansatz der programmierer jst hier für jedes Projekt unter Access einen komplett eigenen Datensatz zu erzeugen 10 Spalten und bis zu 3000 Zeilen welches vom Serverprogramm abgefragt wird.
Für ein einzelnes Projekt ist das Layout ja völlig nachvollziehbar im SQL. Tabelle sample.dbo mit 10 Spalten und 3000 Zeilen.
Aber hat jemand eine Idee wie man das in ein gutes Layout bringt für X Projekte die ja jeweils bis zu 3000 Datensätze mit bis zu 10 Feldern beherbergen?
Eine Tabelle pro Projekt ist ja etwas unkonventionell oder?
Ich hoffe das war nicht zu verworren sonst fragt einfach.
LG
Theo
wir lassen ein Tool schreiben welches Datensätze erstellt und verarbeitet. Die Details würden jetzt etwas zu weit führen aber die programmierer würden die Daten in einem eigenen Serverprogramm speichern. Ich würde die Daten lieber im SQL speichern, bin aber was das Layout angeht gerade etwas überfragt. Folgende Situation:
Ein "Projekt" besteht aus mehreren Datenfeldern (bis zu 3000). Jedes dieser Datenfelder hat selbst nochmal ca. 10 Datenfelder welche hauptsächlich als Strings mit einer Länge von 4-ca. 300 Zeichen vorliegen.
Der Ansatz der programmierer jst hier für jedes Projekt unter Access einen komplett eigenen Datensatz zu erzeugen 10 Spalten und bis zu 3000 Zeilen welches vom Serverprogramm abgefragt wird.
Für ein einzelnes Projekt ist das Layout ja völlig nachvollziehbar im SQL. Tabelle sample.dbo mit 10 Spalten und 3000 Zeilen.
Aber hat jemand eine Idee wie man das in ein gutes Layout bringt für X Projekte die ja jeweils bis zu 3000 Datensätze mit bis zu 10 Feldern beherbergen?
Eine Tabelle pro Projekt ist ja etwas unkonventionell oder?
Ich hoffe das war nicht zu verworren sonst fragt einfach.
LG
Theo
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 325925
Url: https://administrator.de/forum/frage-zu-datenbanklayout-mssql-325925.html
Ausgedruckt am: 02.04.2025 um 04:04 Uhr
9 Kommentare
Neuester Kommentar
Normalisierung lautet das Zauberwort und ist auf Wikipedia beschrieben. Mit deinen Begrifflichkeiten kann ich nicht viel Anfangen, was sind das für 3000 Datenfelder, 3000 verschiedene Atribute?
Grundsätzlich ist eine MSSQL DB Access weit überlegen und Grundsätzlich muss man nur Projekt als Entität mit in das ERD aufnehmen und schon hat man eine DB für alle Projekte. Einzig bei 3000 verschiedenen Atributen könnte man darüber nachdenken nicht mit einer relationalen DB zu arbeiten (also auch kein Access), aber auch hier gibt es Möglichkeiten.
Grundsätzlich ist eine MSSQL DB Access weit überlegen und Grundsätzlich muss man nur Projekt als Entität mit in das ERD aufnehmen und schon hat man eine DB für alle Projekte. Einzig bei 3000 verschiedenen Atributen könnte man darüber nachdenken nicht mit einer relationalen DB zu arbeiten (also auch kein Access), aber auch hier gibt es Möglichkeiten.
Hallo ukulele,
normalisierung guck ich mir auf wiki mla an.
Hier mal ein Schema wie ich das meine. Die Attribite 1-X sind ca. 10. Die "Datensätze" ca. 3000
lg
Theo
normalisierung guck ich mir auf wiki mla an.
Hier mal ein Schema wie ich das meine. Die Attribite 1-X sind ca. 10. Die "Datensätze" ca. 3000
lg
Theo
Das ist dann ein überschaubarer Fall. Eine Tabelle für Projekte, eine für die Daten mit den Atributen als Spalten und einem Fremdschlüssel auf Projekte.
Moin,
dann wäre, ohne die Attribute im Details zu kennen folgender Aufbau geeignet:
ProjektID | Attribut 1 | Attribut 2 | Attribut 3 | Attribut ... | Attribut n
Und da Datensätze in Excelsprache gesprochen ja immer einzelne Zeilen sind, werden diese einfach untereinander gefüllt.
Die ProjektID ist dann deine Projektnummer, also Projekt 1, Projekt 2, Projekt 3, Projekt n
Wenn du einen Primary-Key benötigst, wäre mit dem aktuellen, uns mitgeteiltem Wissen ein künstlicher (zusammengesetzter) zu erzeugen, sodass die Tabelle dann wie folgt aussähe:
Variante 1: Key | ProjektID | Attribut 1 | Attribut 2 | Attribut 3 | Attribut ... | Attribut n
Hierbei ist egal für welches Projekt das Feld Key einmalig
Variante 2: Key | ProjektID | Attribut 1 | Attribut 2 | Attribut 3 | Attribut ... | Attribut n
Hierbei darf die Kombination Key und ProjektID nur einmalig vorkommen. Du kannst so für jedes Projekt jeweils den Key 1 bis x verwenden. Es kann also den Key 4711 sowohl im Projekt 1 als auch im Projekt 3 geben, aber nicht 2x im Projekt 1
Asonsten schaue, was die Attribute so an Inhalt haben, vermutlich kannst du auch hier noch schlanker werden.
z.B. wenn dort Kundendaten (Name Anschrift etc.) hinterlegt sind. Diese kannst du in einer weiteren Tabelle anlegen und den primär-Schlüssel "AnschriftenID" in deine "Haupttabelle" angeben und später beim Auswerten verknüpfen.
Hierzu musst du dir aber in der Tat das Thema "Normalisierung" anschauen.
Gruß
em-pie
dann wäre, ohne die Attribute im Details zu kennen folgender Aufbau geeignet:
ProjektID | Attribut 1 | Attribut 2 | Attribut 3 | Attribut ... | Attribut n
Und da Datensätze in Excelsprache gesprochen ja immer einzelne Zeilen sind, werden diese einfach untereinander gefüllt.
Die ProjektID ist dann deine Projektnummer, also Projekt 1, Projekt 2, Projekt 3, Projekt n
Wenn du einen Primary-Key benötigst, wäre mit dem aktuellen, uns mitgeteiltem Wissen ein künstlicher (zusammengesetzter) zu erzeugen, sodass die Tabelle dann wie folgt aussähe:
Variante 1: Key | ProjektID | Attribut 1 | Attribut 2 | Attribut 3 | Attribut ... | Attribut n
Hierbei ist egal für welches Projekt das Feld Key einmalig
Variante 2: Key | ProjektID | Attribut 1 | Attribut 2 | Attribut 3 | Attribut ... | Attribut n
Hierbei darf die Kombination Key und ProjektID nur einmalig vorkommen. Du kannst so für jedes Projekt jeweils den Key 1 bis x verwenden. Es kann also den Key 4711 sowohl im Projekt 1 als auch im Projekt 3 geben, aber nicht 2x im Projekt 1
Asonsten schaue, was die Attribute so an Inhalt haben, vermutlich kannst du auch hier noch schlanker werden.
z.B. wenn dort Kundendaten (Name Anschrift etc.) hinterlegt sind. Diese kannst du in einer weiteren Tabelle anlegen und den primär-Schlüssel "AnschriftenID" in deine "Haupttabelle" angeben und später beim Auswerten verknüpfen.
Hierzu musst du dir aber in der Tat das Thema "Normalisierung" anschauen.
Gruß
em-pie
Hallo zusammen,
wenn ich das richtige verstehe reduziert sich das dann auf 2 Tabellen. Projekte mit Project ID und Daten mit Fremdschlüssel auf das Projekt.
Wird die Datentabelle dann nicht exorbitant groß? Das sind ja dann schnell einige 100.000 Zeilen und ein vielfaches davon.
lg
Theo
wenn ich das richtige verstehe reduziert sich das dann auf 2 Tabellen. Projekte mit Project ID und Daten mit Fremdschlüssel auf das Projekt.
Wird die Datentabelle dann nicht exorbitant groß? Das sind ja dann schnell einige 100.000 Zeilen und ein vielfaches davon.
lg
Theo
Je nachdem, wie deine Attribute aussehen. Durch Normalisieren (sofern möglich) wird es schlanker.
Aber wenn dir das zu viele Datensätze werden, reicht die Access ohnehin irgendwann nicht mehr, dass muss ein SQL-Server her
Für Access wurden folgende Limits definiert:
https://support.office.com/en-us/article/Access-2016-specifications-0cf3 ...
Beim SQL limitiert die Version den Speicher.... aber hier ist einiges an Platz ;)
Aber wenn dir das zu viele Datensätze werden, reicht die Access ohnehin irgendwann nicht mehr, dass muss ein SQL-Server her
Für Access wurden folgende Limits definiert:
https://support.office.com/en-us/article/Access-2016-specifications-0cf3 ...
Beim SQL limitiert die Version den Speicher.... aber hier ist einiges an Platz ;)
alles klar ich guck mir das nochmla genauer an aber danke euch!
Auch MS SQL Express hat kein Problem mit mehreren Millionen Einträgen in einer Tabelle, ein Index über den FK auf Projekte ist sicherlich erforderlich und man muss die DB Größe im Blick haben, ich glaube max 10 GB ist bei Express noch aktuell.
Jupp, den verwenden wir hier auch für ein kleineres Workflow Tool. Und die 10 GB sollte ich auch nicht sprengen.
LG
Theo
LG
Theo
