nicht angemeldet
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