Eines, und nicht das kleinste deiner Probleme ist, das du einem weit verbreiteten Irrtum unterliegst.
Notes Datenbanken heissen zwar inoffiziell immer noch "Datenbank" (offiziell sind das laut IBM Terminologie Anwendungen), haben aber mit SQL Datenbanken von denen du nach dem was ich hier von deiner Ausbildung gehört habe herkommst, soviel gemeinsam wie ein Fisch mit einem Pferd. Es gibt gewisse, sehr grundlegende, Ähnlichkeiten, das war es dann aber schon.
Was die Informationen angeht hast du doch schon eine Menge bekommen. Vor allem was die möglichen Entscheidungskriterien für oder gegen eine technologische Basis für das System das du da bauen sollst angeht. Und ich kann aus deinen Posts leider nicht mehr erkennen, ob es um die "strategische Planung" des Systems, oder um die "Realisierung in einem gegebenen Umfeld" geht. Das scheint sich im Verlauf der Diskussion hier gewandelt zu haben.
Planen kann man auf einer abstrakten Ebene. Da kommen die von dir genannten Faktoren wie "Erweiterbarkeit, Benutzerverwaltung, Sicherheit oder Zugriffsgeschwindigkeit" zum tragen um sich für ein System zu entscheiden. Wenn dann eine Entscheidung getroffen wurde, dann kann das jeder halbwegs kompetente Entwickler mit den von dir bis jetzt genannten Rahmenbedingungen auf jedem der möglicherweise zur Verfügung stehenden Systeme realisieren, wenn er sich mit diesem System auskennt. Ob du dann derjenige Entwickler sein solltest, das stelle ich jetzt mal, auf Grund deiner letzten Aussagen, in Zweifel.
Wenn dein lokaler IT-Manager da anschließend "einfach Anpassungen"vornehmen können soll, dann hast du hier außerdem doch eh einen Eckpfeiler gesetzt. Dann muss nämlich entweder das System so designed werden, das es auch von "Nichtprogrammierern" verändert werden kann und mit Verändern meine ich jetzt etwas was über "gib ein neues Schlüsselwort an das der Anwender verwenden darf" hinausgeht, dann spielst du was Programmierung und Design angeht weit über deiner aktuellen (2 Semester Datenstrukturen und ein "bischen was mit Access") Gewichtsklasse
, oder du musst dich an die Kenntnisse deiner Umgebung anpassen.
Und du, oder dein <IRONIE>schon etwas blauäugiger</IRONIE> Auftraggeber, kannst dich schon mal auf einen heftigen Kampf mit der zentralen IT einstellen, wenn du mit irgendwelchen Lösungen kommst die "mal eben irgendwo installiert werden sollen". Das haben die Jungs und Mädchen die die großen Systeme betreiben dann überhaupt nicht gerne, wenn da plötzlich irgendwo Anwendungen auftauchen die nicht in Ihre Systeme passen und wenn es auch nur "kleine" Anwendungen sind.
Also noch mal zurück ans Zeichenbrett und deine Anforderungen konkret formulieren, so a la, "Der Anwender braucht ein System im dem er Tabellendaten einfach eingeben kann und mit dem es möglich ist sie dann zu verarbeiten und in strukturierter Form im Format XYZ wieder auszugeben. Das System soll ohne das der Anwender programmieren muss um ABC und Berechnungen UVW erweitert werden können und so weiter und so fort ..."
Wenn du es kannst, alle entscheidungsrelevanten Teile wie Benutzersicherheit, Erweiterbarkeit, etc. genau definieren. Erweiterbarkeit kann zum Beispiel auf Technischer Ebene (Codierung), auf Datenebene (Anzahl der verwaltbaren Datensätze, oder Anzahl der Benutzer der Anwendung) auf Benutzerebene (selbstständiges Eintrage von neuen Schlüsselworten) eine Rolle spielen. Und ich habe jetzt hier ganz bewusst nicht alle verschiedenen Möglichkeiten Erweiterbarkeit zu definieren genannt.
Jeden genau definierten Teil deiner Anforderungen jeweils mit einem Wert belegen und dahinter Zahlen für die Wichtigkeit des Teiles schreiben.
Dann die Realisierbarkeit mit den verschiedenen Systemen und den Aufwand für die Realisierung in dem jeweiligen System ermitteln und Aufschreiben. Zu der Ermittlung der Realisierbarkeit gehört übrigens auch die Frage wo passt das in die aktuelle Landschaft rein und darf ich das überhaupt in dieser Landschaft plazieren.
Danach die Entscheidung treffen und dann erst realisieren. Nicht umgekehrt.
