nicht angemeldet
Variabler Spalteninhalt
Hallo Leute,
ich habe etwa folgende Situation:
Tabelle [Aufgabe]
aufgabe_id
aufgabe_parent_id
author_id
priorität
status
title
Bsp.
1 - 10 3 3 Ölwechsel
2 - 10 3 3 Programmieren
3 - 12 1 1 Auto waschen
4 2 10 3 3 Klasse X programmieren
Parent_ID dient dazu, dass man eine Hierarchie erstellen kann mit Unteraufgaben.
Nun habe ich eine Zusatztabelle, bei der ich die Aufgaben mit bestimmten Typen anreichern/schmücken kann.
Tabelle [Typen]
Bsp.
1 Deadline
2 Milestone
3 Notiz
4 Geplante_zeit
5 Verbrauchte_Zeit
6 Startdatum
7 Erinnerung
8 Preisfeld (es können also alles mögliche an Typen vorhanden sein. Quadratmeter, bla bla)
9 Referenz evtl. auf eine Datei, Pfad, oder die Datei selbst
Tabelle [Aufgaben_zusatz]
aufgaben_zusatz_id
aufgabe_id
typen_id
value
Meine Problem nun genau in der Spalte Value. Hier muss ich zwingend String nehmen, da hier ein Datum (Deadline) sein kann, ein Integer (Geplante_zeit, könnte entweder Stunde, Minuten oder Tage oder Wochen sein) oder ein Text (Notiz) usw.
Ich frage mich nun die ganze Zeit, ob man das evtl. flexibel machen könnte, damit ich zum beispiel ein Deadline auch als Typ "Datetime" oder "Date" in die Spalte einfügen könnte. Oder, bei geplante_zeit könnte es sich um verschiedene Einheiten (Tage, Minuten, Stunden) handeln.
Sollte das alles nun auf String bleiben oder gehe ich total in die falsche Richtung? (Daraus will ich später auch eine Kalenderansicht generieren (falls es nicht so aufwendig wird), bei der die verschiedenen Aufgaben eingetragen werden.
Über Tipps wäre ich euch sehr dankbar. Ich überlege dann noch mal weiter, vielleicht fällt mir da noch etwas ein.
Grüßchen
michi
P.S. Später will ich bei immer wiederkehrenden ähnlichen Aufgaben, die das gleiche Schema aufweisen und bestimmte Typen haben, als Paket einfügen können, wo dann automatisch alle benötigen Typen beim anlegen des Pakets hinzugefügt werden. Das ist aber das kleinere Problem denke ich. Das muss ich halt noch mit berücksichtigen bei der Planung oben
-
Ich frage mich nun die ganze Zeit, ob man das evtl. flexibel machen könnte, damit ich zum beispiel ein Deadline auch als Typ "Datetime" oder "Date" in die Spalte einfügen könnte.
Wenn String, dann String. Das Datum könntest du dann halt in Textform speichern.
oder gehe ich total in die falsche Richtung?
Überdenke die Sache nochmal. Vielleicht fällt dir dann ein dass du nicht nur genau eine dieser Infos speichern musst, sondern evtl. mehrere. Dann könnte es mehrere Spalten für die Zusätze geben.
Oder du kannst mit der Stringdarstellung leben, wenn du nicht allzu üble Casts machen musst.Diese Problematik ist ziemlich eklig, weil man entweder was "unschönes" macht, oder nen Haufen Programmierzeit und auch Speicherplatz in der DB verschwendet. Kenn ich ;-)
-
Hey danke,
Ich frage mich nun die ganze Zeit, ob man das evtl. flexibel machen könnte, damit ich zum beispiel ein Deadline auch als Typ "Datetime" oder "Date" in die Spalte einfügen könnte.
Wenn String, dann String. Das Datum könntest du dann halt in Textform speichern.das ist bisher die einzige gute alternative dir mir zuspricht.
oder gehe ich total in die falsche Richtung?
Überdenke die Sache nochmal. Vielleicht fällt dir dann ein dass du nicht nur genau eine dieser Infos speichern musst, sondern evtl. mehrere. Dann könnte es mehrere Spalten für die Zusätze geben.
Oder du kannst mit der Stringdarstellung leben, wenn du nicht allzu üble Casts machen musst.ja, man kann eine Aufgabe natürlich mit mehreren Zusätzen anreichern. Es können auch manche Anreicherungen mehrmals mit demselben Typ angelegt werden. Ich muss also jedes mal eine neue Zeile einfügen. Und das geht auf den Speicherplatz.
Mir fällt auch auf, wenn ich ein Typ "Startdatum" und "Enddatum" habe und in einem Tast mehrere Start- und Enddaten vorhanden sein können. Dann fängt der Chaos an, welches Startdatum zum Enddatum gehört :-)Diese Problematik ist ziemlich eklig, weil man entweder was "unschönes" macht, oder nen Haufen Programmierzeit und auch Speicherplatz in der DB verschwendet. Kenn ich ;-)
Danke du machst mir Mut. Vor allem, da ich nun weiß, dass ich nicht der einzige mit dem Problem bin, bzw. manch andere den Kopf darüber zerbrechen :-)
Grüße
-
Vielleicht nimmst du ja ein Stringfeld mit etwas mehr inhaltlicher Beschreibung, XML oder so? Da bringst du dann alles unter was du willst und brauchst. Ist natürlich beim Auslesen ein bisschen Fummelei und nicht mehr wirklich in SQL machbar. Aber wenns genügt wärs ja ok.
-
Hi,
Vielleicht nimmst du ja ein Stringfeld mit etwas mehr inhaltlicher Beschreibung, XML oder so? Da bringst du dann alles unter was du willst und brauchst. Ist natürlich beim Auslesen ein bisschen Fummelei und nicht mehr wirklich in SQL machbar. Aber wenns genügt wärs ja ok.
eigentlich wäre eine reine XML-Lösung sicherlich eine sehr gute Lösung ohne eine SQL-Datenbank (Was die datenhaltung angeht. Dann könnte man schön die DTD für die Aufgaben verfassen)
Aber XML über Netzwerk, mehrere und autorisierte Zugriffe gleichzeitig, uvm. mit reinem XML ist denke ich nicht so prickelnd.Wenn es eine DB sein sollte, hatte ich mir auch in einer Zwischentabelle überlegt, wie es kommen würde, wenn man in der Zwischentabelle in einer Spalte eine Referenz auf eine andere Tabelle zeigt
Tabelle [Aufgaben_zusatz]
aufgaben_zusatz_id
aufgabe_id
typen_table (dann hätte ich für jeden typ eine eigene Tabelle, Bsp. Milestone, Duration, Referenz, Notiz usw. und würde dann dort die jeweiligen Zusatzdaten für die jeweilige Aufgabe speichern.Sieht halt sehr hässlich aus. Die Frage ist dann, ob es mit den SQL-Querys naher einen Chaos gibt,wenn man je nach Abfrage auf verschiedene Tabellen zugreifen muss, indem man in der Tabelle "Aufgaben_zusatz" überprüft, in welchen Tabellen noch Zusätze für die jeweilige Aufgabe liegt. (Ist glaub etwas verwirrend geworden)
Grüße
-
Hi,
eigentlich wäre eine reine XML-Lösung sicherlich eine sehr gute Lösung ohne eine SQL-Datenbank (Was die datenhaltung angeht. Dann könnte man schön die DTD für die Aufgaben verfassen)
Aber XML über Netzwerk, mehrere und autorisierte Zugriffe gleichzeitig, uvm. mit reinem XML ist denke ich nicht so prickelnd.Kommt drauf an - zum Beispiel auf der Verhältnis von lesenden zu schreibenden Zugriffen.
Und über Requests hinaus im Speicher halten könnte man es ggf. auch, dann muss man nicht jedes mal Dateien einlesen.
Die Frage ist dann, ob es mit den SQL-Querys naher einen Chaos gibt,wenn man je nach Abfrage auf verschiedene Tabellen zugreifen muss, indem man in der Tabelle "Aufgaben_zusatz" überprüft, in welchen Tabellen noch Zusätze für die jeweilige Aufgabe liegt.
Dynamisch innerhalb einer Query zu bestimmen, aus welchen weiteren Tabellen noch Informationen hinzu geJOINT oder sonstwie gezogen werden sollen, ist m.W. gar nicht praktikabel möglich.
Der Weg Query -> Script/Programm -> neue Query ist natürlich möglich, aber auch nicht unbedingt schön.
Vielleicht ist „echtes“ SQL aber auch gar nicht das richtige für dein Vorhaben - und mit einer NoSQL-DB würdest du besser fahren, hast du in die Richtung schon mal überlegt?
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Kommt drauf an - zum Beispiel auf der Verhältnis von lesenden zu schreibenden Zugriffen.
Und über Requests hinaus im Speicher halten könnte man es ggf. auch, dann muss man nicht jedes mal Dateien einlesen.
Das Problem ist, dass an einer Aufgabe mehrere Leute gleichzeitig arbeiten könnten, also konkurierende Zugriffe. Ob jetzt mehr lesend oder schreibend kann ich jetzt nicht sagen. Es wird eine Software, die lokal auf dem Geschäfts-PC auch später auf dem Smartphone (abgespeckte Version auf einem Android) laufen.
Die Frage ist dann, ob es mit den SQL-Querys naher einen Chaos gibt,wenn man je nach Abfrage auf verschiedene Tabellen zugreifen muss, indem man in der Tabelle "Aufgaben_zusatz" überprüft, in welchen Tabellen noch Zusätze für die jeweilige Aufgabe liegt.
Dynamisch innerhalb einer Query zu bestimmen, aus welchen weiteren Tabellen noch Informationen hinzu geJOINT oder sonstwie gezogen werden sollen, ist m.W. gar nicht praktikabel möglich.
Ja, das hatte ich mir eh schwer vorgestellt. Also sollte ich mir dann nicht noch mehr Gedanken in diese Richtung machen und nach anderen alternativen suchen.
Der Weg Query -> Script/Programm -> neue Query ist natürlich möglich, aber auch nicht unbedingt schön.
Stimmt.
Vielleicht ist „echtes“ SQL aber auch gar nicht das richtige für dein Vorhaben - und mit einer NoSQL-DB würdest du besser fahren, hast du in die Richtung schon mal überlegt?
Ich hatte nie von noSQL gehört. Danke, ich habe mir schon gleich ein paar Seiten gespeichert, um mir diesbezüglich Informationen zu sammeln. (Die ersten Beschreibungen sagen Sachen wie schemafrei und skalierbar. Mal schauen, vielleicht wäre es ja ein guter Weg :)
Also relational lässt sich das (nach meinem eher unerfahrenen Kenntnisstand) nur schwer/nicht schön, weswegen ich jetzt mal nach Alternativen suche.Ich schreibe dann wieder, ob das noSQL evtl. eine gute Alternative ist
-
-
eigentlich wäre eine reine XML-Lösung sicherlich eine sehr gute Lösung ohne eine SQL-Datenbank
Ich dachte an ein Stringfeld in deiner Tabelle, in dem XML steht. Dann hättest du nur ein einziges Feld für verschiedene Inhaltstypen und könntest den Inhalt durch das XML entsprechend strukturieren. Wenn was hinzukommt wärs ken Problem, du kannst beschreiben was da wirklich drin steht usw.
-
Hi,
Ich dachte an ein Stringfeld in deiner Tabelle, in dem XML steht. Dann hättest du nur ein einziges Feld für verschiedene Inhaltstypen und könntest den Inhalt durch das XML entsprechend strukturieren. Wenn was hinzukommt wärs ken Problem, du kannst beschreiben was da wirklich drin steht usw.
ich denke, das wird die beste Lösung sein. Für einen Prof. wäre die Lösung auch nicht so hässlich ne? :-)
-
Hi,
Ich dachte an ein Stringfeld in deiner Tabelle, in dem XML steht. [...]
ich denke, das wird die beste Lösung sein.
Wenn du aber mal irgendwann in diesen Daten suchen willst, wirst du das vermutlich anders sehen.
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hi,
Ich dachte an ein Stringfeld in deiner Tabelle, in dem XML steht. [...]
ich denke, das wird die beste Lösung sein.
Wenn du aber mal irgendwann in diesen Daten suchen willst, wirst du das vermutlich anders sehen.
siehe dann, an das hatte ich überhaupt nicht gedacht. wird immer mehr verzwickter. Ich habe eine gute PDF bzgl. noSQL gefunden, die mache ich heute abend durch: http://isabel-drost.de/projects/tuberlin/imsem2010/nosql_paper_2010.pdf
Grüße
-
-
-
-
-
-
-