fähiges Personal

[fuenfsterne]

Werte Damen und Herren,

erstmal ein herzliches Hallo an alle Forumsmitglieder.

Ich bin neu hier und stehe vor einer, nunja, sagen wir mal so: einer sicherlich nicht unüberwindbaren Hürde, doch mir ist sie definitiv zu hoch... Für den Aufbau einer Kundendatenbank inkl. der Anlage von Produkten habe ich mich etwas näher mit Access beschäftigt. Grundlegend scheint Access alle notwendigen Funktionen mitzubringen, doch die Programmierung gestaltet sich als etwas schwieriger als angenommen. Ich habe zwar ein paar Grundkenntnisse in der Programmierung, doch diese sind A) bei Access absolut nicht gefragt und B) absolut nicht ausreichend. Ich habe zwar überlegt, mich da selbst reinzufuchsen, habe auch angefangen und bin schon ein paar Schritte vorangekommen, doch mittlerweile stehe ich da vor Herausforderungen die für mich nicht lösbar sind. Nicht ohne Hilfe von außen!!!

Ich würde mich freuen, wenn mir jemand weiterhelfen könnte.

Ich habe mir diese Vorlage von Microsoft geladen und möchte diese noch ein wenig praktikabler machen und erweitern: http://office.microsoft.com/de-de/templates/CT010211577.aspx?tl=2#ai:TC001225342|

Eine Tabelle anzulegen und auch über ein Formular mit Daten zu bestücken habe ich mitbekommen wie das geht. Hier habe ich bereits einige zusätzliche Felder eingefügt und mit Daten bestückt. Das funktioniert auch. Nur das praktikable Einbinden der Untertabellen in denen die Produkte eingepflegt werden, die zu dem Kunden gehören ist die aktuell zu meisternde Aufgabe.
Ich möchte in den Kontaktdetails einen Button haben. Wenn ich auf diesen klicke, dann soll ein Formular aufgehen, in dem ich das Produkt mit den Eigenschaften anlege. Dieses Produkt soll in der Untertabelle bei dem Kunden abgespeichert werden. Auf einem weiteren Reiter in den Kontaktdetails möchte ich dann die eingegebenen Produkte als Bericht einsehen können.
Wenn jetzt bei dem Kunden schon ein Produkt besteht, und ich auf den button klicke, dann soll das Fenster auch aufgehen und ich lege eben ein zweites Produkt an. Oder ein drittes, oder viertes.

Weiterhin sollen Berichte erstellt werden können, mit denen ich dann Einzelheiten zu den Kunden Anzeigen lassen kann und aber auch Berichte in denen beispielsweise alle Produkte (unter allen Kunden) mit den und den Eigenschaften angezeigt werden, also sprich, das nur die Untertabellen aller Kunden ausgewertet werden.

Meine Frage ist, ob mit jemand dabei weiterhelfen kann und ob mein Anliegen prinzipiell überhaupt realisierbar ist.

Weiterhin interessiert mich, wie man externe Dokumente einbindet. Ich möchte diese nicht in der Datenbank haben, sondern es soll nur ein Link zu einer Ordnerstruktur hinterlegt werden.

Ich spreche hier von einer Datenbank mit >1000 Kunden, pro Kunde etwa >100 Datensätze und Pro Kunde mehr als 15 Produkte mit jeweils >50 Datensätzen.

Ist das überhaupt praktikabel realisierbar? Wie sieht es mit einer Portierung in andere Datenbanken aus?

Fragen  über Fragen  , aber so ist es nun mal, wenn man neu hier ist...

Ich würde mich freuen, wenn mir jemand weiterhilft!

Viele Grüße sendet


Matthias

[Jonny]

Hallo Matthias,
Natürlich lässt sich das von Access hervorragend lösen.

Du hast ja viel geschrieben aber nicht so richtig was passieren soll.

a) Willst du das ganze extern programmieren lassen?
b) Willst du es selber machen?

zu b:
hier habe ich das Gefühl, dass bei dir das Verständnis für Datenbanken allgemein sehr gering ist.
Von Access hast du sicherlich auch schon etwas gehört aber auch hier scheinen mir die Grundkenntnisse zu fehlen.

Ich will dir nicht zu Nahe treten aber wenn du die Lösung b möchtest musst du wahrscheinlich erstmal
Grundkenntnisse sammeln.

Gruß

Johann

[Wurliwurm]

Ich habe zwar überlegt, mich da selbst reinzufuchsen, habe auch angefangen und bin schon ein paar Schritte vorangekommen, doch mittlerweile stehe ich da vor Herausforderungen die für mich nicht lösbar sind. Nicht ohne Hilfe von außen!!!

Hallo Matthias,

in der Tat ist Dein Vorhaben ergeizig. Es stellen sich folgende Fragen:

-Hilfe von außen aus einem Forum ist problematisch, wenn Du eine genaue Auskunft brauchst, aber immer nur einer antwortet, der gerade Zeit und Lust hat
-Wie wichtig ist die Datenbank? Nachdem Access nur für kleine Desktopanwendung vorgesehen ist, mußt Du immer mit Datenverlust rechnen. Access ist im Vergleich zu einer aktiven Datenbank für konkurrierendes Schreiben nur rudimentär ausgestattet. Access-Datenbanken können u.U. auch plötzlich unbenutzbar werden, dann ist die aktuelle mdb nicht mehr brauchbar. Es gibt keine Re-Do-Logs, beim Crash kannst Du immer nur auf die letzte kopierte mdb zurückgreifen. Für geschäftskritische Anwendungen ist Access nicht geeignet.
-Ablage auf dem Desktop oder im Netz? Im Zugriff über das Netz wäre eine Datenbank der angegebenen Größe kaum noch benutzbar.

Weiterhin interessiert mich, wie man externe Dokumente einbindet. Ich möchte diese nicht in der Datenbank haben, sondern es soll nur ein Link zu einer Ordnerstruktur hinterlegt werden.

Du kannst in einem Textfeld die URL speichern, das wäre kein Problem.

Ich spreche hier von einer Datenbank mit >1000 Kunden, pro Kunde etwa >100 Datensätze und Pro Kunde mehr als 15 Produkte mit jeweils >50 Datensätzen. Ist das überhaupt praktikabel realisierbar? Wie sieht es mit einer Portierung in andere Datenbanken aus?

Wenn Du das für Dein Geschäft brauchst, warum machst Du Dir dann die Mühe? Du würdest viele hundert Stunden brauchen, wenn Du etwas wirklich brauchbares zusammenbauen wolltest. Es gibt viele fertige Lösungen.

Außerdem wärst Du mit Access immer an Microsoft und VBA gebunden. Wenn Du dich in eine  freie Datenbank (wie mySQL) einarbeiten würdest, hättest Du mehr Möglichkeiten zu skalieren.

Für eine Adressdatei oder eine kleine Aufgabenverwaltung ist Access sicherlich das beste. Man kann es schnell lernen. Aber es gerät schnell an seine Grenzen. Mit einer anderen Datenbank hast Du vielleicht keine so steile Lernkurve, es wäre m.E. langfristig aber lohnender.

[Jonny]

Hallo Wurliwurm,

deine Aussagen über Access kann ich so nicht stehen lassen. So schlecht wie du es darstellst ist es nicht
was ich dir an viele schon seit Jahren laufende Anwenden beweisen könnte.
z. B. Auskunftssystem mit ca. 250.000 Artikel mit Verfügbarkeit nach Lager, bestellt, Bestellmöglichkeit beim Lieferanten
Zusammensetzung im Detail. Entwickelt mit Acc-95!!! und nur kleine Anpassungen an neue Anforderungen.
Läuft auf einen Server mit Zugriff von bis zu 6 Mitarbeitern. Telefonauskunft ist möglich,.

Auch andere Anwendungen von mir laufen schon seit Jahren.

Bei Matthias bin ich schon der Meinung das für diese Aufgabe zu wenig Grundkenntnisse vorhanden sind.
Aber dazu muss er sich erstmal melden.

Gruß

Johann

[Wurliwurm]

deine Aussagen über Access kann ich so nicht stehen lassen. So schlecht wie du es darstellst ist es nicht

Hallo Johnny,

ich meine nicht, es als schlecht dargestellt zu haben, sondern nur, daß es ab einer einer bestimmten Größe und Anforderungen an die Datenqualität keine so gute Wahl mehr ist. Als Vergleich: Auch mit Excel kann man tolle Dinge machen, unter anderem auch Daten speichern, aber trotzdem ist es als Datenspeicher nicht besonders gut geeignet. Diese Aussage heißt nicht, Excel schlecht zu machen.

Access in einer Größe von dem Auskunftssystem, das Du beschrieben hast ist schon beeindruckend. Aber wahrscheinlich skaliert es nicht mehr, dass heißt, 2,5 Mio Datensätze oder 60 User gehen nicht mehr. Ich kenne Access vor allem als Auswertungstool, das heißt die Daten werden als Dump regelmäßig aus einer großen Datenbank gezogen und dann im Access Queries gemacht. Zum Beispiel dient das Access dann als Datenquelle für Excel (Diagramme etc...). Als OLTP-System mit konkurrierenden Schreib- und Lesezugriffen ist Access nicht verbreitet. Ich möchte nicht mein Konto bei einer Bank führen, die die Kontoinformationen in Access speichert.

Die große Schwäche von Access (das habe ich schon mal ausgeführt) ist die File-Server-Architektur, z.B. Queries werden auf dem Client verarbeitet von der Jet dll und es muß erst einmal alles über das Netz. Wie schnell geht das in Deiner Auskunft-Datenbank, wenn drei Anwender gleichzeitig eine gruppierte Abfrage mit Having-Bedingung machen? (etwa alle Artikelgruppen, von denen insgesamt genau 23 Stück vorhanden sind). In einer aktiven Datenbank muß vielleicht nur jeweils ein Paketchen mit der SQL-Anfrage über das Netz und es kommt 1 KB Treffermenge zurück.

Bei Matthias bin ich schon der Meinung das für diese Aufgabe zu wenig Grundkenntnisse vorhanden sind.

Wenn er noch nichts kann, dann kann er sich auch in ein aktives Datenbanksystem einarbeiten, zum Beispiel in Microsoft SQL Server (die freie Version), MySQL oder die Express Version von Oracle. Da wird der Anfang zwar weh tun, weil er nicht einfach sich die Sachen so einfach zusammenklicken kann. Dafür hat er aber vieles mehr wie unterschiedliche User mit genauer Rechtevergabe, Logging und erweiterte Möglichkeiten, die Datenqualität zu kontrollieren wie Trigger, Stored procedures und vieles mehr.

Wir können hier gerne fachsimpeln, aber wahrscheinlich meldet er sich eh nicht mehr...

[ebs17]

Ich kenne Access vor allem als Auswertungstool, das heißt die Daten werden als Dump regelmäßig aus einer großen Datenbank gezogen und dann im Access Queries gemacht.

Das ist nun das eigentlich Grauselige: Warum muss man eine solche "fürchterliche Desktop-Datenbank" wie Access verwenden, wo man doch eine richtige Datenbank zur Verfügung hat. Kann man nicht einfach dort die Queries bereit stellen, die benötigt werden. Statt sich mit dem Finger die Nase hochzuhalten, sollte die IT besser so arbeiten, dass Fachabteilungen gar nicht erst auf solche Ideen kommen können oder müssen und Reports (also unnormalisierte Daten) irgendwie verwurschten müssen.

Daneben ist Access unwidersprochen bestens geeignet, einfach und schnell ein GUI für eine Datenbank (egal ob als Backend SQL Server, PostgreSQL, MySQL oder File-Backends) zu erstellen.

Und: Wenn man sein Produkt kennt und richtig anwendet, kann man mit der kleinen Lösung (Access) sehr viel leisten. Wer wie der Threadersteller froh ist, eine Tabelle und ein Formular zu erstellen, denkt wohl kaum an 60 permanent gleichzeitig arbeitende User und Millionen Datensätze pro Tabelle, sondern vielleicht nur einfach daran, sich selber (ganz alleine) die Arbeit etwas zu erleichtern. Wenn ich statt spazieren laufen möchte, brauche ich noch keinen Ferrari auf einer Autobahn.

MfGA
ebs

[oma]

Hallo Johannes,

auch wenn du rein formal in den Punkten recht hast kann ich die Diskussion in einem Access-Forum nicht so recht nachvollziehen.
Viele User hier haben schon leistungsstarke DBs entwickelt;  die "Schwächen" für eine Access-Anwendung sind bekannt, für Matthias evt. nicht, aber ihn nun mit solchen Thesen als Einsteiger zu bearbeiten erscheint mir wenig zweckmäßig . Zumal nach meinen Erfahrungen die Grenzen von Access eher überschätzt werden!
Nach Abschätztung der Daten von Matthias erscheint doch Access ein sehr geeignetes Werkzeug zu sein (wenn man von nicht "zu vielen" Nutzern ausgeht).  Insofern stimme ich Johann zu.

Und übrigens: 

und es muß erst einmal alles über das Netz.

auch wenn man das vielfach liest, wird es dadurch nicht richtig!

Gruß Oma

[oma]

Hallo ebs,

warst gerade etwas schneller; arbeitest du etwa auch mit solch fürchterlichen Werzeug wie MS-Access?

Gruß Oma

[ebs17]

arbeitest du etwa auch mit solch fürchterlichen Werzeug wie MS-Access?

Ja. Siehe auch Status von Access.

Übrigens muss man sich auch in Access nicht auf (verfügbare!) Assistenten verlassen (also irgendetwas irgendwie zusammenklicken), sondern man kann auch
- gescheite Prozeduren unter Einbeziehung von Klassen programmieren,
- effektive Abfragen schreiben.

Eine kräftigere Maschine (DBMS) bedeutet nicht zwingend, dass man auch schneller und besser fahren kann. Die vorhandene oder mögliche Straße und Fähigkeiten des Fahrers spielen da auch eine wesentliche Rolle.

[Wurliwurm]

Kann man nicht einfach dort die Queries bereit stellen, die benötigt werden. Statt sich mit dem Finger die Nase hochzuhalten, sollte die IT besser so arbeiten, dass Fachabteilungen gar nicht erst auf solche Ideen kommen können oder müssen und Reports (also unnormalisierte Daten) irgendwie verwurschten müssen.

Mit Queries können nur noch die Poweruser arbeiten, selbst mit Access als Datenquelle kommen viele nicht zurecht. Normalisiert brauchen die Daten in einer Reporting-Datenbank eh nicht sein, das ist nur bei Update-lastigen Datenbanken ein Thema.

Daneben ist Access unwidersprochen bestens geeignet, einfach und schnell ein GUI für eine Datenbank (egal ob als Backend SQL Server, PostgreSQL, MySQL oder File-Backends) zu erstellen.

Absolut. Meine Vorbehalte beziehen sich nur auf die Jet-Engine. Access kann mit aktiven Datenbanken schneller und stabiler besser zusammenarbeitenals mit der Jet-Engine. Die Lernhürde ist dabei, ADO zu lernen.

Wer wie der Threadersteller froh ist, eine Tabelle und ein Formular zu erstellen, denkt wohl kaum an 60 permanent gleichzeitig arbeitende User und Millionen Datensätze pro Tabelle, sondern vielleicht nur einfach daran, sich selber (ganz alleine) die Arbeit etwas zu erleichtern. Wenn ich statt spazieren laufen möchte, brauche ich noch keinen Ferrari auf einer Autobahn.

Sicherlich.

Ich habe mir die Präsentation von der Entwicklerkonferenz, die Du hochgeladen hast, angesehen und fand Sie sehr interessant. Da ist eigentlich schon alles gesagt. Vielleicht fehlt aber noch als Ergänzung die Kategorisierung der Access-Freunde, zum Beispiel den Accesser, der alles, was irgendwie gerade noch halbwegs mit Access lösbar ist, unbedingt mit Access lösen will. Diese "Krankheit" ist verwandt mit der Excelitis. :-)

Übrigens: Man kann im Laborversuch die Jet-Engine leicht in die Knie zwingen. Dazu muß man nur eine MDB starten, die in einer Schleife bestimmte Daten immer wieder liest. Dazu noch mindestens zwei mdb starten, die ebenfalls in einer Schleife diese Daten immer wieder löschen und neu anlegen. Wenn man die Geschwindigkeit der Schreibe-mdbs erhöht (die Wartezeit zwischen zwei Durchläufen auf unter 500ms etwa verringert), dann hagelt es bald Fehler, es kommt zu dirty reads und das Backend bläht sich auf bis es platzt. Mit einer aktiven Datenbank hingegen sieht man, was Serialisierung bedeutet: Es läuft seidenweich wie ein Zwölfzylinder, ohne Knattern und Fehlzündungen.

[Wurliwurm]

Nach Abschätztung der Daten von Matthias erscheint doch Access ein sehr geeignetes Werkzeug zu sein (wenn man von nicht "zu vielen" Nutzern ausgeht).  Insofern stimme ich Johann zu.

Hallo Oma,

wahrscheinlich hast Du recht. Soll er es mit Access machen, besser als Excel ist es dafür allemal.

und es muß erst einmal alles über das Netz.

auch wenn man das vielfach liest, wird es dadurch nicht richtig!

Wo soll bitte die Verarbeitung zum Beispiel bei einer gruppierten Query mit Having-Bendigung (wo also die Selektionsbedingungen erst nach der Gruppierung angewandt werden können) denn stattfinden, wenn nicht auf dem Client? Vielleicht hat Jet da einen lokalen Puffer, aber dann entsteht Overhead durch die Synchronisierung dieses Puffers.

[Jonny]

Hallo Johannes,
toll was man alles so feststellen kann um Acc schlecht zu machen.

Nimm ein DB-Modell was hier gebraucht wird und wo die Normalisierung gut durchdacht ist.
Nimm die Tabellenzugriffe mit DAO oder ADO.
Stelle vernünftige SQL-String zusammen und mache den Set damit.
Lasse die Laborgeschichte weg, die braucht hier keiner
und du wirst feststellen das man einiges mit Acc machen kann.

Ach ja wir sind hier übrigens in ein Access-Forum wo die Mitglieder mit Acc arbeiten
und dazu Fragen haben. Andere Mitglieder versuchen zu helfen und das Ganze
führt auch noch zum Erfolg.

Gruß

Johann

[Wurliwurm]

toll was man alles so feststellen kann um Acc schlecht zu machen.

Wir reden hier aneinander vorbei. Was soll die Trotzhaltung?
Kannst Du als Access-Profi differenzieren zwischen Kritik an der Jet Engine und Empfehlung von Access als RAD?

Nimm die Tabellenzugriffe mit (...) ADO.

Ach was? Das meine ich doch! ADO ist für Zugriff auf aktive Datenbanken da. Man braucht da nur die Parameter der Connection ändern, und schon ist man weg von Jet.

Hier ein anderer Access-Profi zu Deiner Empfehlung von ADO:

http://books.google.de/books?id=PO22n_tT9YIC&pg=PA308&lpg=PA308&dq=baloui+ado+dao&source=bl&ots=k_fQWsvFIF&sig=9ZPMVGT_hNT7klwdasIFNA1wAwM&hl=de&sa=X&ei=s4cqT8-0DdHNswbrre2eDQ&ved=0CCIQ6AEwAA#v=onepage&q=baloui%20ado%20dao&f=false

"...für Access- Anwender/Programmierer ist jedoch das ältere DAO vorzuziehen, da es optimal an die Jet Engine und Access-Datenbanken angepasst ist und ohne jede Einschränkungen alles zur Verfügung stellt, was für den Umgang mit diesem Datenbanktyp benötigt wird - und das so einfach wie möglich!

Zumindest, solange Sie als Access-Anwender/Programmierer nahezu ausschließlich das tun, was zu vermuten ist: lokale Access-Datenbanken erzeugen und programmieren. Dann sollten Sie das ältere, für diesen Zweck aber besser geeignete DAO verwenden.

ADO sollten Sie einsetzen, wenn Sie zwar Access benutzen, ungewöhnlicherweise an Access-Datenbanken aber nur am Rande oder gar überhaupt nicht interessiert sind. Wenn Sie Access eigentlich nur als Frontend zum Zugriff auf Datenbanken benutzen wollen, die sich auf einem Oracle-, MS SQL-Server oder wo auch immer befinden. .."

[ebs17]

Mit Queries können nur noch die Poweruser arbeiten

Das heißt übersetzt: Sei Poweruser (was immer das sein soll) oder lasse strikt die Finger von jeglicher Datenbank. Welch ein Unsinn!

Abfragen sind die erste Verarbeitungsschicht auf Daten, die in Tabellen liegen, und zwar eine extrem wichtige und leistungsfähige. Der Verzicht darauf heißt Verzicht auf Datenbankarbeit.

Ein User sollte übrigens Ergebnisse bekommen und nicht selber Abfragen erstellen müssen. Dafür ist dann der Entwickler zuständig - und sicher auch dafür, dass ein Reporting im "schnurrenden" DBMS vollendet wird und nicht auf Access oder Excel ausweichen muss, dann noch oft betreut von eher Anfängern, Praktikanten u.a., die nicht schnell genug weglaufen können.

Übrigens: Man kann im Laborversuch die Jet-Engine leicht in die Knie zwingen.

Man kann auch mit den Tellern seines Meißner Prozellans Nägel in die Wand einschlagen. Aber wer macht so etwas. Man muss sein Produkt schon kennen und richtig einsetzen.

Datenbankarbeit heißt nicht zwangsläufig, die Betriebsdaten eines mittelständigen Unternehmens zu verwalten, sondern durchaus auch eine Verwaltung eines Vereins, einer Kochrezeptesammlung, einer privaten CD-/DVD-Sammlung u.a., und das schlicht lokal (ohne Netzwerk). Dafür wird dann auch niemand ein Oracle aufsetzen, weil es doch so schön leistungsfähig ist.

MfGA
ebs

[Wurliwurm]

Datenbankarbeit heißt nicht zwangsläufig, die Betriebsdaten eines mittelständigen Unternehmens zu verwalten, sondern durchaus auch eine Verwaltung eines Vereins, einer Kochrezeptesammlung, einer privaten CD-/DVD-Sammlung u.a., und das schlicht lokal (ohne Netzwerk).

Ursprünglich war die Rede von

>1000 Kunden, pro Kunde etwa >100 Datensätze und Pro Kunde mehr als 15 Produkte mit jeweils >50 Datensätzen.

Das ist schon eine ganz andere Dimension als eine CD- oder Kochrezeptesammlung. Das sind schon durchaus mitteldständische Dimensionen.

Dafür wird dann auch niemand ein Oracle aufsetzen, weil es doch so schön leistungsfähig ist.

Doch, ich. :-) Aber das vielleicht eine Berufskrankheit.

Der 08/15-User wird für solche Sache wahrscheinlich eh Excel benutzen.