Es grüßt Euch ein Neuer, der von Programmieren keine Ahnung hat, davon aber jede Menge ...
Ich habe eine sehr umfangreiche Software auf Excel entwickelt (Bausektor), die ich vermarkten möchte.
Derzeit baue ich die Software in Access neu auf, weil sich Excel als Verkaufssoftware nicht eignet.
Natürlich brauche ich Unterstützung von einem Profi, aber wegen der gewaltigen Menge an Berechnungen muss ich selbst Hand anlegen, anders wäre das unbezahlbar.
Also habe ich eine Namenskonvention aufgebaut und erstelle die vielen Tabellen zuerst in Excel, um sie dann in Access zu übertragen.
Meine Frage:
Ich habe zahllose Dropdown-Menüs, viele bedingt.
Jedes dieser Auswahllisten umfasst ca. 3 - 8 Felder.
Muss ich für jede dieser Listenfelder eine eigene Tabelle einrichten?
Das wären uferlos viele.
Hallo,
ZitatAlso habe ich eine Namenskonvention aufgebaut und erstelle die vielen Tabellen zuerst in Excel, um sie dann in Access zu übertragen.
was verstehst Du in diesem Zusammenhang unter Namenskonvention?
Datenbanktabelle in Excel anzulegen um diese nach Access zu übertragen geht meistens schief.
Access erfordert eine völlig andere Tabellenstruktur als Excel.
Ist Dir im Zusammenhang mit einer Datenbank der Begriff "Normalisierung" geläufig?
ZitatMuss ich für jede dieser Listenfelder eine eigene Tabelle einrichten?
Das wären uferlos viele.
Auch bei dieser Frage sind wir wieder bei Normalisierung.
Wo sollen die Daten herkommen, wenn nicht aus einer Tabelle?
Die Anzahl der Tabellen ist bei Access relativ bedeutungslos. Es werden so viele Tabellen benötigt, bis das Datenmodell mindestens der 3. Normalform entspricht.
Das Programmieren, ist bei Access zunächst mal völlig, aber wirklich völlig nebensächlich. Für die Datenbank an sich, ist gar nichts zu programmieren.
Und alles was Du von Excel weist, kannst Du bei Access nicht verwenden, nur mal noch als kleine Warnung.
Auf Basis Access eine verkaufbare Anwendung zu entwickeln, ist auch für einen Access Profi eine Herausforderung.
Zeige mal ein Beispiel, für 2-3 Access Tabellen.
Mit Namenskonvention meine ich, allen Tabellen und Feldern solche Namen zu geben, die sie eindeutig machen und gleichzeitig noch lesbar.
Es werden grob geschätzt 2.000 Tabellen werden, vielleicht mehr, da ist es wichtig, nicht irgendwelche Kürzelnamen zu nehmen, die man später nicht mehr zuordnen kann.
Natürlich programmiere ich das nicht selbst, sondern erstelle "nur" die Tabellen, fülle sie mit Inhalt und erstelle die Abfragen, von denen viele wiederum in Tabellen kommen. Wie Du schreibst, spielt Programmieren bei Access keine Rolle. Diese 2.000 Tabellen sind meist überschaubar kurz, im Mittel 20 Datensätze, nur einige Tabellen sind deutlich länger, ca. 3.000 Datensätze. Dürfte aber für Access kein Problem sein.
Ich übertrage die Exceldaten auch nicht automatisch in Access, sondern nutze mein Excel nur als optische Vorlage. Ich tippe dann jede Exceltabelle händisch in Access, sonst geht das wirklich schief.
Bei den meisten Tabellen ist mir der Ablauf klar, bei einigen nicht, z. B. - was meine Frage war - ob ich für jedes Dropdown-Menü eine eigene Tabelle anlegen soll oder ob ich dafür eine große Tabelle verwenden kann, die ich "irgendwie" in Bereiche gliedere, um mit SELECT diesen Bereich in ein Listenfeld zu holen.
Ich knabbere momentan eben noch an grundsätzlichen Fragen:
- Ist Access die richtige Datenbank?
- Bekomme ich die Daten später in eine C#-WPF-Anwendung?
Die späteren Nutzer öffnen die Software und müssen/dürfen eine sehr umfangreiche Eingabemaske ausfüllen, deren Menüsteuerung später noch eine Aufgabe sein wird. Das sind in Excel derzeit ca. 20.000 Zeilen mit je ca. 6 Spalten. Also eine Menge Felder, denen ich wohl allen Namen geben muss.
Diese ca. 100.000 Eingaben werden dann auf Tabellen verteilt, um durch Rechenabfragen Ergebnisdateien zu schaffen, die der Kunde am Ende ausdrucken kann. Allein das Ausdruckbare sind ca. 500 DIN A4-Seiten.
Wie gesagt, der gewaltige Umfang der Software erfordert eine gute Architektur, an der ich schon Wochen tüftle. Klar könnte das ein Programmierer besser, andererseits steckt die Software voller Branchenwissen, das wiederum ich habe. Also möchte ich meinen sinnvollen Teil leisten und das sind die Tabellen und Abfragen. Andernfalls wäre das auch gar nicht finanzierbar.
An der Excel-Vorlage habe ich 2 Jahre intensiv gearbeitet, ohne das wäre es vollkommen unmöglich, diese Software jetzt aufzusetzen.
Mich würde eine Antwort freuen, die konkret meine Frage beantwortet:
Muss für jedes Dropdown eine eigene Tabelle angelegt werden?
Hallo,
ZitatMuss für jedes Dropdown eine eigene Tabelle angelegt werden?
ja, alles andere ist Krampf. Und eine große Tabelle ändert ja nichts am Aufwand und mit einer großen Tabelle wird die Datenmenge größer, weil ja ein Feld zur Unterscheidung dazu kommt.
Wenn ich das alles lese, habe ich erhebliche Zweifel am Datenmodell. Aber darauf gehst Du ja nicht ein. Und auf meine Frage ob Du den Begriff "Normalisierung" kennst bist Du auch nicht eingegangen.
Wenn mit diesen vielen Tabellen das Datenmodell stimmt, ist Access nicht geeignet.
ZitatMuss für jedes Dropdown eine eigene Tabelle angelegt werden?
NEIN. Man könnte auch Wertelisten als Datenherkunft einsetzen. Dann sind aber die Werte hardcodiert, und selbst bei geringstem Änderungs/Ergänzungswunsch muss der Entwickler ran.
Deutlich pflegeleichter ist die Datenherkunft Tabelle/Abfrage. Hier könnte dem Anwender eine zusätzliche Oberfläche (Formular) angeboten werden, wo Tabellenwerte ergänzt/geändert werden. Der Hinweis Abfrage verdeutlicht aber auch, dass nicht zwingend nur Tabellen verwendet werden können. Abfragen sind nicht zwingend "Krampf" - es kommt darauf an (was und wer).
ZitatBekomme ich die Daten später in eine C#-WPF-Anwendung?
Das kommt darauf an, was diese Anwendung kann. Access-Tabellen/-Abfragen lassen sich fast ebenso leicht übernehmen wie Exceltabellen. Zur Not könnte man einen Export in eine CSV vornehmen, mit der dann so ziemlich jede Anwendung zurechtkommen wird, die einen Datenimport zulässt.
ZitatAlso eine Menge Felder, denen ich wohl allen Namen geben muss.
Spalten = Felder, und die sechs Felder haben bereits mit Tabellenerstellung ihre Namen.
ZitatIst Access die richtige Datenbank?
Unter der Voraussetzung, dass die DB fachmännisch (und nicht laut Excel-Intuition) aufgebaut wird, Datenmengen ein Stück unter 2 GB liegen und keine erhöhten Datensicherheitsanforderungen bestehen: Durchaus. Formulare kannst Du bspw. deutlich einfacher und schneller erstellen als in Excel.
Allerdings müsste man sich auch die Berechnungen anschauen. Jet-SQL ist etwas eingeschränkt im Befehlsumfang, so dass auch aus dieser Sicht die Verwendung eines aktiven DBMS als Backend zu betrachten wäre.
Und 2.000 Tabellen stimmen mich auch ein wenig nachdenklich ...
MfGA
ebs
Genau um die Fragen geht es:
Ist Access die richtige Lösung?
Vielleicht eher nicht bei dieser Datenmenge bzw. Komplexität der Abfragen.
Von Oracle gibt es eine in-Memory-DB (Oracle times ten).
Bei dieser Lösung wird das komplette Projekt auf den Client-PC geladen, sodass die Abfragen deutlich schneller ablaufen.
Aber wie ist es hier mit der Sicherheit, auch der Ausfallsicherheit?
Aber für meine Tabellen dürfte das momentan keine Rolle spielen.
Ich will sie nur in der richtigen DB aufbauen, um nicht noch einmal von vorne anfangen zu müssen.
Die bisherigen Antworten auf meine Frage, ob kleine Dropdowns in einzelnen Tabellen gespeichert werden sollen, waren: Ja, auf einzelne Tabellen.
Ok, dann mach ich das so.
ZitatKomplexität der Abfragen
Wo nimmst Du das her?
Wenn Du natürlich die Excellogik auf eine Datenbank übertragen willst (egal welche), wird es haarig.
Zitatauf den Client-PC geladen, sodass die Abfragen deutlich schneller ablaufen
Lokaler statt Netzwerktraffic ist nur ein Kriterium für Performance und bei weitem nicht das einzige.
Andere Kriterien wären z.B. verarbeitungsgerechte (SQL-gerechte) Strukturen, Indexnutzung, Abfragedesign, i/O-Operationen auf Festplatte uva.
Ausfälle sind bei Datenbanken, wenn diese nicht mit haarigen Problemen zusammengesetzt wurden, nun nicht das große Thema. Bei Sicherheit sprach ich eher vom Schutz von sensiblen Daten, der über eine Access-DB nicht ausreichend realisiert werden kann.
ZitatDie bisherigen Antworten auf meine Frage, ob kleine Dropdowns in einzelnen Tabellen gespeichert werden sollen, waren: Ja ...
Und noch einmal: NEIN.
MfGA
ebs
Natürlich übertrage ich die Excellogik nicht auf eine Datenbank.
Ohne Excel hätte ich den Software-Rohling nie entwickeln können, nun heißt es aber Umdenken zum Datenbankschema.
Also Access wird wohl nicht ausreichend sein, auch weil jemand, der Access hat, die Datei ggf. öffnen kann.
Der Kunde soll aber lediglich eingeben. Nichts formatieren, nichts ändern, nur Eingeben.
Meine Software kann man sich vorstellen wie PowerPoint:
Seite 1 komplett (!) ausfüllen, weiter zu S. 2, usw.
Einige Seiten werden übersprungen, je nach Kundenprojekt.
Also Dropdowns könnten in eine Werteliste, mit Semikolons getrennt.
Das Hardcodierte stört nicht, weil der Nutzer nichts an den Dropdowns ändern kann.
Bedingte Dropdowns müssten dann ja auch über die Werteliste funktionieren.
Das wäre natürlich super, weil das Tabellen spart.
Um die Tabellen ginge es mir ja nicht, aber die Übersicht im Explorer wird halt arg schwierig bei vielen 100 Tabellen.
Da lohnt es sich schon, darüber nachzudenken, Tabellen sinnvoll zusammenzulegen, wegen der Übersichtlichkeit.
Oracle scheint die professionellste DB zu sein, liege ich da richtig mit meinem Halbwissen ;)
Das mit dem "in-Memory" war nur so eine Idee, könnte aber die Datensicherheit schwächen.
Danke für die Antworten, mühsam ernährt sich das Eichhörnchen.
Um keinen falschen Eindruck zu erwecken:
Ich programmiere das nicht selbst, dafür ist die Software zu kompliziert.
Aber ich habe schon 2 Jahre daran gearbeitet und weiß bis ins Detail, wie sie funktionieren muss.
Das dürfte ja immer die Krux sein:
Der Kunde (also ich) kennt sich mit Programmieren nicht aus, hat aber Branchenwissen.
Der Programmierer kennt die (Bau-)Branche nicht, kann aber programmieren.
Und deshalb mache ich die Tabellen selbst, weil ich genau weiß, was hineingehört.
Mag sein, dass dann nicht alle Felder richtig deklariert sind, aber das kann man korrigieren.
Falsche Feldinhalte jedoch wären eine Katastrophe.
Fühl mich manchmal wie ein Eunuch:
Ich weiß, wie es gehen soll, kann's aber nicht ...
Hallo,
Nach meiner Auffassung kann man keine Datenbank entwickeln ohne fundierte Kenntnisse zur Entwicklung relationaler Datenbanken. Und schon gar nicht in dem Umfang der hier erforderlich wird/ist. Hier ist eine korrekt angelegte, normalisierte Struktur erforderlich mit allen drum und dran was zu einer DB gehört.
Zu Deinem Kenntnisstand (zu Datenbankentwicklung) hast Du noch nichts verraten, trotz mehrmaliger Bitten.
Du erstellst jetzt die Tabellen, füllst diese mit Daten und dann kommt der Datenbankentwickler, wirft einen Blick auf die Tabellenstruktur und wird alles verwerfen.
Ich würde fast eine Wette eingehen, dass es so kommt. ;D
Und das mit der Wertelist geht zwar, aber ob das wirklich was spart möchte ich bezweifeln. Die Werte müssen ja auch in die Werteliste kommen.
Und die Einschränkungen zu Wertelisten hat Ebs ja auch gemacht.
Hallo,
ZitatUnd das mit der Wertelist geht zwar, aber ob das wirklich was spart möchte ich bezweifeln.
Dem möchte ich beipflichten.
Es stellt sich ja nicht die Frage ob's machbar ist oder nicht.
Zum Einen ist es durch die Wertelisten mit der Normalisierung vorbei zum Anderen haben Dropdowns in einer
Tabelle eigentlich nichts zu suchen.
Hallo,
mein Kenntnisstand zu Datenbankentwicklungen? Das Prinzip der Normalisierung habe ich verstanden, auch dass man für m:n-Tabellen eine Hilfstabelle braucht, welche beide IDs aufnimmt, usw. Meine bisherigen Tabellen haben keine Redundanzen und wenn doch, weiche ich bewusst davon ab, etwa wenn ich Vor- und Nachname in ein Feld gebe, weil meine Datentabelle zu Adressen nur 4 Einträge hat und man Bauherren in Formularen anders anspricht.
Ich habe lange an der Namensgebung gefeilt, um die vielen Tabellen immer zuordnen zu können.
Es gibt ja noch ein weiteres Kriterium für gute Tabellen, nämlich was sie enthalten. Und hier kenne ich mein Projekt eben besser als jeder Programmierer.
Ich gebe ja nicht alle Tabellen ein und schau dann mal, sondern teste immer wieder kleine Einheiten.
Ich hatte mir für meine Software Angebote eingeholt, was die Entwicklung kosten würde, wenn ich gar nicht mitmache: ca. 200.000 - 500.000 €.
Also auch von diesem Gesichtspunkt aus wäre das nicht darstellbar, weil ich ja nicht weiß, welchen Markterfolg sie später mal haben wird. Das würde nämlich gegen meine persönliche 4. Regel der Normalisierung verstoßen: Schulden machen.
Man muss immer von dem ausgehen, was konkret vorhanden ist und daraus das Beste machen. Nicht nur bei einer Software ...
Das mit den Wertetabellen probiere ich aus und wenn das nichts ist, gibt es eben ca. 400 Tabellen mehr, ist ja dann auch schon egal.
Meine Dropdowns enthalten Fachbegriffe, die sowieso in Tabellen stehen müssen.
Stellt Euch eine riesenlange Materialliste vor, z. B. Autowerkstatt.
Ein Auto besteht aus sehr vielen Bauteilen.
Die Bauteile gehören zu Gruppen (Motorteile, Elektronik, Innenausstattung, usw.).
Beispiel Motor
Wer einen Diesel auswählt, erhält andere Auswahlmenüs als bei einem Benziner.
Ein Vierzylinder enthält wieder andere Auswahlmenüs, es gibt aber auch Überschneidungen.
So klickt man sich in die Details, die Auswahlmenüs hängen voneinander ab.
Da die Bauteile sowieso in Listen stehen, muss man nun dafür sorgen, dass eine davon "wissen" sollen, dass sie zu einem Auswahlmenü gehören.
Hallo,
Zitat200.000 - 500.000 €.
:o
Willst Du SAP installieren?
Und vermutlich gibt es für solche (Auto-) Material-Stücklisten anderweitig schon fertige Software...
Zu den Kombi-Auswahlen:
Zitat
Ich habe zahllose Dropdown-Menüs, viele bedingt.
Jedes dieser Auswahllisten umfasst ca. 3 - 8 Felder.
Dazu braucht man keine "zahllosen" Tabellen, es genügt eine, wenn man davon ausgeht, dass es sich bei den "Feldern" um Einträge (Datensätze) handelt, die nur aus dem auszuwählenden (nachzuschlagenden) Wert bestehen.
Kongret und prinzipiell:
tbl_CmbAuswahl:
KombiIndex ListWert (Sortierfeld) (ParentID)
1 A (1)
1 B (2)
1 C (3)
2 10 (2)
2 15 (3)
2 05 (1)
2 30 (4)
3 Alles (3)
3 Nichts (1)
3 Wenig (2)
mit einer Abfrage je Kombi (hier z. B. für Kombi2)
Select ListWert from tbl_CmbAuswahl where Kombiindex =2 order by Sortierfeld
Mit vernünftiger Kombibenamsung und ein bisschen VBA-Code lassen sich so beliebige Kombilisten einfach (über Pflege mit einem Formular) erzeugen und die Kombis "füllen".
Würde ich SAP programmieren, hätte ich ja einen eigenen Fußballverein... ;)
Und in der Autobranche bin ich auch nicht, das mit den Autoteilen war nur ein Beispiel.
Vielen Dank für Deine tab.
Mit KombiIndex + Sortierfeld kann ich ListWerte zuordnen und könnte so zumindest einige Auswahlmenüs in 1 Tabelle packen.
Bei einer doppelt bedingten Abfrage bräuchte ich vermutlich noch eine KombiIndex-Spalte.
Beispiel, diesmal aus dem BauBereich
Klick auf "Bauweise"
A Massivbau
B Holzbau
Klick auf A:
A1 Ziegel
A2 Ytong
A3 Kalksandstein
...
Klick auf A1
A11 Planziegel
A12 Blockziegel
...
Klick auf A11
A111 perlitgefüllte Planziegel
A111 ungefüllte Planziegel
Klick auf A111
A1111 T7
A1112 T8
...
Löst man diese 4-fach bedingte Auswahl dann über 4 KombiIndex-Spalten?
Und wenn ja, dann wären diese Spalten bei allen Feldern leer, wo es keine bedingte Auswahl gibt.
Zitat von: accessoire am Juli 01, 2013, 17:12:12
Klick auf "Bauweise"
A Massivbau
B Holzbau
(...)
Klick auf A11
A111 perlitgefüllte Planziegel
A111 ungefüllte Planziegel
Hier springt auch dem Nicht-Baustofffachmann die funktionale Abhängigkeit ins Auge:
A111 Ziegel -> ... -> A Massivbau
Das bedeutet auch, daß hier Hierarchien (Baumstruktur) zu modellieren sind. Dazu braucht man wenige möglichst generische Tabellen und nicht soviele Einzeltabellen. Eigentlich wäre ein Treeview hier angebracht und nicht eine unüberschaubare Menge von Auswahlboxen mit unüberschaubaren Abhängigkeiten. Schon allein deshalb, weil sonst die Tiefe der Auswahl immer gleich sein muß.
Das, was Du vorhast, dürfte Dich erschlagen ohne Kenntnisse von Datenmodellierung und Programmierung.
Ein Treeview kommt nicht in Frage, weil das aus meiner Sicht zu Nutzer-unfreundlich ist.
Der Nutzer klickt (um beim BauBeispiel zu bleiben) auf "Massivbau".
In der nächsten Zelle klickt er auf "Ziegel".
Die Eingabe ist umfangreich genug, da will ich die Nutzer nicht mit Baumstrukturen usw. nerven.
Es gibt ca. 300 solcher Auswahlfelder, jedes hinterlegt mit i. M. 5 Auswahlen = 1.500 Baustoffe
Von den 300 sind ca. 100 bedingt.
Von diesen 100 sind einige zweifach bedingt, einige dreifach und vierfach. Mehr als 4 Ebenen habe ich derzeit nicht.
"Jeder kennt jeden Menschen auf dieser Welt um max. 6 Ecken."
Das hat sicher ein DB-Programmierer entdeckt, aber es stimmt wohl.
Also brauche ich sicher nicht mehr als 6 Ebenen ... ;D
Würde ich alle 1.500 in eine Tabelle geben, wäre das Problem, dass sie nicht auf denselben Ebenen sind.
Der perlitgefüllte Planziegel liegt auf der tiefsten Ebene 4, andere Elemente haben keinen Tiefgang und liegen auf Ebene 1
Es gäbe also jede Menge leerer Felder.
Das, was ich da vorhabe, erschlägt mich bereits. Ich habe am Donnerstag einen Termin mit einem Programmierer, damit er mir eine allgemeine Struktur anlegt, die ich dann mit Daten fülle. Noch versuche ich nur, das Prinzip zu verstehen, doch es zeigt sich, dass es nicht ein Prinzip gibt, sondern viele.
Hat nicht der Rühmann gesagt: Einem deutschen Inscheniör ist nüchts zu schwör.
Anscheinend doch.
Auf Excel läuft das Monster ja schon, das ist ja das Schlimme.
Nun muss ich von vorn anfangen, weil ich natürlich einsehe, dass sich das als Excel nicht verkaufen lässt, der Datenschutz nicht gegeben ist und auch Updates auf einem Server kaum möglich sein dürften. Es gibt hier zwar Lösungen wie Aspose.Cells oder SpreadsheetGear, aber davon habe ich mich innerlich erst einmal verabschiedet.
Ich würde gerne für diese bedingten Auswahlmenüs eine sinnvolle Lösung finden, von A111 Ziegel -> ... -> A Massivbau.
Hallo,
ZitatIch würde gerne für diese bedingten Auswahlmenüs eine sinnvolle Lösung finden, von A111 Ziegel -> ... -> A Massivbau.
http://www.donkarl.com/?FAQ4.36
http://www.dbwiki.net/images/6/6f/AccSampleKombiAuswahl.zip