Laden...

Im SQLite automatisch Spalten erstellen lassen

Erstellt von Kriz vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.767 Views
K
Kriz Themenstarter:in
141 Beiträge seit 2017
vor 4 Jahren
Im SQLite automatisch Spalten erstellen lassen

verwendetes Datenbanksystem: SQLITE

Guten Morgen Freunde der Sonne,
Ich braucht eine Tabelle mir 365 Spalten. Durchnummeriert von 1 - 366. Gibt es bei sqlite von Haus aus eine Möglichkeit Spalten automatisch erzeugen zu lassen, oder muss ich das über eine for Schleife in C# machen?

Vielen Dank im voraus!
kriz

C
2.121 Beiträge seit 2010
vor 4 Jahren

Ich würde das über eine Schleife machen.

Vorher würde ich darüber nachdenken ob du das wirklich brauchst. So ein Ansatz deutet auf einen Fehler bei den Überlegungen hin. Eine zweite Tabelle die auf die erste verweist und die die 365 Spalten jeweils als eigene Zeile speichert, könnte deine Anforderung sauberer lösen.

K
Kriz Themenstarter:in
141 Beiträge seit 2017
vor 4 Jahren

Was wäre denn der Vorteil der zweiten Variante?
In der aktuellen Situation kann ich mit meinem Reader direkt auf die passende Spalte zugreifen.
In deinem Vorschlag müsste ich ja dann die komplette Zeile einlesen, splitten, um dann auf den passenden Eintrag/Spalte zugreifen zu können.
Wäre das schneller bzw speichersparsamer?

16.806 Beiträge seit 2008
vor 4 Jahren

Naja, sein Vorschlag basiert einfach auf den Grundlagen von SQL Design.
Normalisierung (Datenbank)

T
2.219 Beiträge seit 2008
vor 4 Jahren

@Kriz
Du bräuchtest im Endeffekt nur eine Tabelle mit der Information aus welcher Zeile und Spalte der Eintrag kommt.
Um die Performance kannst du dich dann per Index kümmern.
Oder falls möglich kannst du direkt einen zusammengesetzen PK aus Zeile und Spalte bilden, was dann den Index über den PK liefert und auch sicherstellt, dass es keine Dubletten in der Tabelle geben kann.
Hängt aber von dem Anwendungsfall bei dir ab.
Mehr Details zu dem Zweck des Ganzen wären hilfreicher um dir eine mögliche Lösung zuempfehlen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

K
Kriz Themenstarter:in
141 Beiträge seit 2017
vor 4 Jahren

Die Situation ist folgende:

Es wird ein Dienstplan für ein Restaurant geschrieben. Dieses Restaurant hat jeden Tag im Jahr geöffnet (jaja, die armen Gastronomen!), daher die 365 Spalten. Nun bekommt jeder Mitarbeiter eine eigene Zeile, mit den IDs für die Schichten je Tag. Die Schichten sind dann in einer separaten Tabelle wo auch die Pausen und sonstige weitere Informationen abgelegt sind.
Nun arbeitet natürlich niemand 365 Tage durch, somit wird die ein oder andere Spalte bei den Mitarbeitern leer sein.
Aktuell habe ich es so gelöst, dass ich die Dienstpläne wochenweise speicher.
Dafür habe ich folgende Tabellen:

  1. Tabelle mit Informationen zum Dienstplan (Dienstplan ID, Startdatum, Notizen, usw)

  2. Tabelle die einer Dienstplan ID die passenden Mitarbeiter mit den Verweisen zu den gearbeiteten Schichten verknüpft. Pro Dienstplan ID gibt es mehrere Zeilen, pro Mitarbeiter eine. Das angefügte Bild veranschaulicht es vllt etwas. (DiID = Dienstplan ID, MiID = Mitarbeiter ID, und unter den Tagen sind die jeweiligen IDs für die gearbeiteten Schichten)

  3. Tabelle für die gearbeiteten Schichten inkl Pausenzeiten usw.

Das wirkt für mich langsam alles wie eine "Flickschusterei" und etwas umständlich, besonders wenn ich Auswertungen vornehmen möchte wann wer wie gearbeitet hat, wieviel Mitarbeiter durchschnittlich zu einem einem bestimmten Zeitpunkt da sind und so weiter.
Daher dachte ich mir, dass ich einfach eine Jahrestabelle erstelle...

T
111 Beiträge seit 2005
vor 4 Jahren

Hallo

Für dein Problem brauchst Du doch nur eine Tabelle mit 4 Spalten:

**
DiID | MiID | Datum | Schicht
**

Damit kannst Du alle Tage die ein Mitarbeiter arbeiten soll eintragen und entsprechend auch suchen.

Thomas

K
Kriz Themenstarter:in
141 Beiträge seit 2017
vor 4 Jahren

Die Idee hatte ich auch, aber wie sieht es da mit der Performance aus? Nehmen wir mal an, wir haben 100 Mitarbeiter die alle eine fünf Tage Woche haben und keinen Urlaub machen, dann haben wir 26.000 Einträge. Ist das eine normale Größenordnung, oder werden Abfragen da länger dauern? Mein Kenntnisstand bei Datenbanken ist eher rudimentär...

463 Beiträge seit 2009
vor 4 Jahren

Nehmen wir mal an, wir haben 100 Mitarbeiter die alle eine fünf Tage Woche haben und keinen Urlaub machen, dann haben wir 26.000 Einträge. Ist das eine normale Größenordnung, oder werden Abfragen da länger dauern? Mein Kenntnisstand bei Datenbanken ist eher rudimentär...

Ist die Frage jetzt dein Ernst? Mit 26.000 Einträgen langweilt sich der SQL Server - Wir haben Tabellen mit mehr als 10 Millionen Einträgen.

TIPP: Grundlagen des SQL Servers helfen auch in der Entwicklung von Anwendungen auf Datenbasis SQL

W
113 Beiträge seit 2006
vor 4 Jahren

Mit 26.000 Einträgen langweilt sich der SQL Server

Es geht hier zwar um SQLite, aber auch die SQLite Engine kommt problemlos mit 26.000 Zeilen klar.

Im Gegensatz dazu könnte es bei sehr vielen Spalten schon eher mal zu Problemen kommen.

Außerdem:

Premature Optimization Is the Root of All Evil

T
2.219 Beiträge seit 2008
vor 4 Jahren

@Kriz
Du solltest dir das Thema Datenbanken sowie Indizierung mal genauer anschauen.
Auch für Sqlite gelten die gleichen Grundlagen.
Die Performance von Datenbanken wie SQL Server, PostgreSQL und Sqlite sind schon extrem hoch.
Mit der richtigen Hardware Kosntellation und auch normalisierter und optimierter Datenbank kannst du auch mit zig Millionen Einträgen ohne Probleme arbeiten.

Kleine Tabellen haben sogar noch den Vorteil, dass diese vollständig in den RAM passen können und somit eine noch höhere Performance beim Lesen erhalten können.
Also mach dir bei der Tabelle keinen Kopf über die Performance.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

K
Kriz Themenstarter:in
141 Beiträge seit 2017
vor 4 Jahren

Alles klar, dann werde ich den Ansatz von Thomas.at verfolgen.
Vielen Dank für Eure Hilfe!!

463 Beiträge seit 2009
vor 4 Jahren

Noch eine kleine Anmerkung zu der - nun auch von dir - bezorzugten Lösung:

Hättets du deinen Plan umgesetzt, hätte dein SQL Befehl wahrscheinlich so in der Art ausgeschaut:


SELECT * FROM Dienstplan

da du unmöglich alle 365 Spalten in deinen SQL Befehl aufnehmne kannst. Soltest du jetzt auch nur eine Spalte in der Datenbank verschieben hast du ein gewaltiges Problem, da dein Ergebnis nun eine andere Form hat. Mit der jetzigen, neuen Lösung kannst du folgenden SQl Befehl ausführen


SELECT dp.DiID, 
       dpd.MiID, 
       dpd.Datum, 
       dpd.Schicht 

FROM Dienstplan AS dp 

INNER JOIN Dienstplan_Detail AS dpd ON dpd.ID = dp.DID

Vorteil: Deine Spalten sind immer gleich - egal wie Sie auf den SQL Server liegen. Noch dazu ist der Befehl SELECT * ein absolutes NoGo!

Achtung: Der SQL Befehl ist nur als Beispiel zu sehen