Erstellung einer komplexen Office_Lösung

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo,

ich brauche mal einige Tipps und entsprechende Begründungen.

Es geht um die Erstellung einer recht komplexen Warenwirtschaft, welche auch einen Onlineshop steuern kann.

Alle Daten werden local in einer SQLite DB gespeichert.

Hier geht es zunächst nur um die allgemeine Frage; sollte man alle Tabellen (Adressen, Artikel, Einkäufe, Verkäufe, Kontobuchungen, Shopdaten…) wirklich in eine DB packen, oder ist es evlt. sinnvoller, zumindest in 2 oder 3 DBs aufzuteilen?

Falls Aufteilung; welche Tabellen sollten in einer DB und mit welchem Hintergrund sollte man das so machen?

Allgemein; gibts allgemeingültige Planungshinweise für so eine Anwendung?

Danke euch sehr.

Grüße
John

#2

Moin, John,

sollte man
alle Tabellen (Adressen, Artikel, Einkäufe, Verkäufe,
Kontobuchungen, Shopdaten…) wirklich in eine DB packen

ja. Es gibt keinen vernünftigen Grund, ohne Not zu verteilen.

Allgemein; gibts allgemeingültige Planungshinweise für so eine
Anwendung?

Hm. Das ist eigentlich das, was man nach hinreichend Berufserfahrung kann :wink:

Allgemeingültiges, das über Allgemeinplätze hinausgeht, kenne ich leider nicht. Der wichtigste Grundsatz heißt KISS - keep it small & simple.

Gruß Ralf

#3

Hallo John,

Es geht um die Erstellung einer recht komplexen
Warenwirtschaft, welche auch einen Onlineshop steuern kann.

sollte man
alle Tabellen (Adressen, Artikel, Einkäufe, Verkäufe,
Kontobuchungen, Shopdaten…) wirklich in eine DB packen,

Ja, das ist doch der Sinn einer DB, dass Du deine Daten zusammen hast. Sonst müsstest Du mehrere DB bei Abfragen miteinander verknüpfen, ob und wie das ginge, wüsste ich jetzt gar nicht zu sagen. Mit reinen SQL-Befehlen dürfte es jedenfalls, wenn überhaupt möglich, sehr mühsam werden.

Falls Aufteilung; welche Tabellen sollten in einer DB und mit

Was Du mit

welchem Hintergrund

meinst, verstehe ich jetzt nicht. Lässt sich auch nicht ohne Kenntnis der erforderlichen Daten sagen.

gibts allgemeingültige Planungshinweise für so eine
Anwendung?

Na ja, es gibt für jede Planung einer Datenbank den „Königsweg“ der Normalisierung
http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/cha…
(gibt noch mehr Links, einfach mal nach Normalform oder Normalisierung googeln).

Aber , und verstehe mich jetzt bitte nicht falsch: Wäre es für solch eine komplexe Anwendung nicht besser, etwas „von der Stange“ zu kaufen, bzw. eine passende Lösung von einem DB-Profi schneidern zu lassen, der sich solch grundlegende Fragen nicht mehr stellen muss? Immerhin hängt allerhand an so einer DB dran und eine schlecht entworfene Lösung macht mehr Ärger als man sich vorstellen kann.

Viele Grüsse
Jan

#4

Ja, das ist doch der Sinn einer DB, dass Du deine Daten
zusammen hast. Sonst müsstest Du mehrere DB bei Abfragen
miteinander verknüpfen, ob und wie das ginge, wüsste ich jetzt
gar nicht zu sagen. Mit reinen SQL-Befehlen dürfte es
jedenfalls, wenn überhaupt möglich, sehr mühsam werden.

Na ja, es gibt für jede Planung einer Datenbank den
„Königsweg“ der Normalisierung
http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/cha…
(gibt noch mehr Links, einfach mal nach Normalform oder
Normalisierung googeln).

Aber , und verstehe mich jetzt bitte nicht falsch: Wäre
es für solch eine komplexe Anwendung nicht besser, etwas „von
der Stange“ zu kaufen, bzw. eine passende Lösung von einem
DB-Profi schneidern zu lassen, der sich solch grundlegende
Fragen nicht mehr stellen muss? Immerhin hängt allerhand an so
einer DB dran und eine schlecht entworfene Lösung macht mehr
Ärger als man sich vorstellen kann.

Viele Grüsse
Jan

Hallo Jan,

danke dir. Gut, dann mache ich alles, oder zumindest fast alles in eine DB, jedenfalls alles, was irgendwie zusammen gehört, und somit auch mit entsprechenden SQL Abfragebefehlen auch sehr praktisch abgefragt werden kann.

Ja, schon klar, die Sache mit der Normalisierung kenne ich.

Mir ist schon klar, dass ein Programmierprofi sowas recht zügig machen könnte. Viel schneller als ich. Aber dann müsste ich den bezahlen, und ich selber hätte nicht den Spaß…

Grüße
John

#5

ja. Es gibt keinen vernünftigen Grund, ohne Not zu verteilen.

Allgemein; gibts allgemeingültige Planungshinweise für so eine
Anwendung?

Hm. Das ist eigentlich das, was man nach hinreichend
Berufserfahrung kann :wink:

Allgemeingültiges, das über Allgemeinplätze hinausgeht, kenne
ich leider nicht. Der wichtigste Grundsatz heißt KISS - keep
it small & simple.

Gruß Ralf

Hi Ralf,

wegen der Berufserfahrung; nun, man kann ja mal fragen, wie andere das machen. Ich selber habe schon meine Vorstellungen…

Was meinst du mit „Allgemeinplätze“ ???

Das mit dem KISS das mache ich immer so, weil anders kann es ja (fast) jeder.

Grüße
John

#6

Hi John,

wegen der Berufserfahrung; nun, man kann ja mal fragen, wie
andere das machen. Ich selber habe schon meine
Vorstellungen…

eine Office-Lösung setzt sich aus dermaßen vielen Aspekten zusammen, dass einfach kein Einstieg zu finden ist. Die Datenbank ist ja nur eine Komponente, dazu kommen das Anwendungsdesign, das Handling, die Performance, der Datenschutz, die Sicherheit, die Kosten, wasweißichnochalles. Und oben drüber steht der Kunde, der seine eigenen Ideen hat (die ihm der ernsthafte Berater oft genug ausreden muss).

Was meinst du mit „Allgemeinplätze“ ???

Ungefähr sowas wie KISS - jeder kennt es, jeder will es, keiner kann es :wink:

Gruß Ralf

#7

eine Office-Lösung setzt sich aus dermaßen vielen Aspekten
zusammen, dass einfach kein Einstieg zu finden ist. Die
Datenbank ist ja nur eine Komponente, dazu kommen das
Anwendungsdesign, das Handling, die Performance, der
Datenschutz, die Sicherheit, die Kosten, wasweißichnochalles.
Und oben drüber steht der Kunde, der seine eigenen Ideen hat
(die ihm der ernsthafte Berater oft genug ausreden muss).

Was meinst du mit „Allgemeinplätze“ ???

Ungefähr sowas wie KISS - jeder kennt es, jeder will es,
keiner kann es :wink:

Gruß Ralf

Hallo Ralf,

ich weiss durchaus, dass viele Dinge bedacht werden müssen. Ich habe bereits eine komplette Warenwirtschaft programmiert, die auch auch ein paar hundert mal verkauft habe. Das Ding soll komplett neu erstellt werden, diesmal mit onlineshop Unterstützung.

Was du mit „Allgemeinplätze“ meinst, habe ich jedoch immer noch nicht verstanden.

Das „KISS“ Konzept kenne ich wörtlich (KISS) auch nicht, aber genau so programmiere ich :smile:

Grüße
J

#9

Ralf, vielleicht noch dies zum Verständnis;

ja, ich habe eine komplette Warenwirtschaft geschrieben. Damit hatte ich ca. 1000 Stunden Zeitaufwand. Das bedeutet aber doch nicht, dass ich so hochnäsig sein muss, und nicht andere Progger fragen könnte, wie man denn dieses oder jenes am besten angeht.

Oder sehe ich das falsch? Nagut, dann eben falsch.

Grüße
J

#10

Hi John,

Das bedeutet aber doch
nicht, dass ich so hochnäsig sein muss,

davon ist doch keine Rede.

und nicht andere Progger fragen könnte, wie man denn
dieses oder jenes am besten angeht.

Es wäre halt hilfreich, wenn nach diesem oder jenem gefragt würde, dann ließen sich auch Antworten dazu finden.

Oder sehe ich das falsch? Nagut, dann eben falsch.

Nicht falsch - anders :wink:))

gruß Ralf