Senifor79
Anmeldungsdatum: 22. Februar 2012
Beiträge: 415
|
Hallo zusammen, die Schule braucht ein Einrichtungsprogramm für einen Raum mit allen Gerätschaften etc. Es soll dazu eine Datenbank genutzt werden.
Das Programm soll am Ende auf einem Windows-System laufen. Ich selbst möchte unter Ubuntu entwickeln.
Meine Frage ist jetzt, ob für die JDK Lizenzgebühren anfallen ?
Gedacht habe ich an MySQL (so wie ich gelesen hab, ist für Schulen keine kommerzielle Lizenz notwendig) und das Frontend mit Java zu programmieren vielleicht mit Eclipse. Wie sieht es da mit den Lizenzen aus ? Kann ich die ohne Gebühren nutzen ?
Kenne mich da leider überhaupt nicht aus .... Vielen Dank. Senifor
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
Wenn es die Anforderungen zulassen, könntest Du auch auf SQLite zurückgreifen. Das ist im Handling in vielen Punkten einfacher als ein echter DB-Server. Wenn Du Multi-User Betrieb brauchst und ggf. auch Berechtigungen, fällt das natürlich flach ☺ (Ansonsten bin ich ja auch eher ein Freund von PostgreSQL 😀 )
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
Lysander schrieb: Wenn es die Anforderungen zulassen, könntest Du auch auf SQLite zurückgreifen. Das ist im Handling in vielen Punkten einfacher als ein echter DB-Server. Wenn Du Multi-User Betrieb brauchst und ggf. auch Berechtigungen, fällt das natürlich flach ☺
SQLIte ist etwas trickreich unter Java, geht aber hiermit gut. Ansonsten gibt es ja noch Java DB bzw. Derby.
(Ansonsten bin ich ja auch eher ein Freund von PostgreSQL 😀 )
👍 Insbesondere, da es ja eher um größere Datenmengen geht und man vielleicht einen separaten Datenbankserver haben möchte, den man von überall her anfragen kann.
|
Senifor79
(Themenstarter)
Anmeldungsdatum: 22. Februar 2012
Beiträge: 415
|
Danke für EUre Antworten.
Hab heute mit einem Verantwortlichen gesprochen. Leider wußte er wohl nicht genau, was ich mit Datenbankserver meinte. Er versprach mir, sich an den Admin zu wenden. Ich werde sehen, welches DBMS ich am Ende nutzen werde. Auch um die Lizenzen muss ich mich nicht kümmern ... schon mal ein Problem weniger. Ich seh in dem ganzen Lizenzkram überhaupt nicht durch ... und dabei immer Angst Fehler zu machen.
Persönlich finde ich eine eingebettete Datenbank sehr schlecht, wegen der fehlenden Berechtigungen. Deshalb kommt SQLITE, ACCESS nicht in Frage ... wenn der Admin aber einen Datenbankserver verweigert, geht es nicht anders.
Ihr könnt ja nochmal schreiben, warum ihr welches DBMS nutzt, welche Vorteile und Nachteile ... wäre interessant. Gruß, Senifor
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
Senifor79 schrieb: Persönlich finde ich eine eingebettete Datenbank sehr schlecht, wegen der fehlenden Berechtigungen. Deshalb kommt SQLITE, ACCESS nicht in Frage
Access ist eh doof 😎 Aber wozu brauchst Du denn die Berechtigungen? Im Grunde handelt es sich dabei ja oft um Datenschutz bzw. auch Schutz der Daten vor Leuten, die an die DB zwar dran müssen, aber eben nicht alles sehen / manipulieren dürfen. Wenn man solche Mechanismen nicht nutzt oder braucht, sehe ich in SQLite viele Vorteile gegenüber einem zu wartenden DBMS-System. Es kommt halt immer auf die Anforderungen an. Wie ich schon sagte ist PostgreSQL das *beste* freie und offene relationale DBMS, das es gibt. Punkt. ☺
|
Senifor79
(Themenstarter)
Anmeldungsdatum: 22. Februar 2012
Beiträge: 415
|
Es sollen viele Leute an der Datenbank arbeiten können, aber nicht alle dürfen alles ... und das Frontend soll auf mehreren Rechnern laufen.
Das wäre das Optimum. Habe ich eine eingebettete Datenbank, dann muss ich auf jedem Rechner eine separate Datenbank pflegen (das Projekt könnte auch so angelegt werden) und dann kommen böswillige Leute und löschen Tabellen oder löschen Datensätze oder oder ... muss nicht mal böswillig sein .... Wie ich schon sagte ist PostgreSQL das *beste* freie und offene relationale DBMS, das es gibt. Punkt. :-) Erklär das doch mal genauer. Warum ist es das beste ? Ich kann leider nicht vergleichen, weil ich bisher nur mySQL genutzt habe. Du scheinst da eindeutig tiefer in der Materie zu stecken als ich ....
Merci. Gruß, Senifor
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
Ganz kurz nur, weil ich heute keine Zeit mehr habe: Du solltest Dein Frontend nicht *direkt* auf die DB zugreifen lassen! Lass die Kommunikation mit der DB immer über einen zentralen (Web-)Service laufen. Das erhöht die Sicherheit und trägt dazu bei, Logik und GUI sauber zu trennen. Wenn viele Leute nur parallel lesen, wäre SQLite immer noch eine Option. Ach weißt Du, Aussagen wie ich sie getätigt habe sind *immer* stark subjektiv und emotional. Schau Dir Postgres einfach mal an; es hat so viele Aspekte, die ich besser finde als bei MySQL. Schemata, besseren SQL-Standard, keine "Storage"-Engines, sondern *ein* einheitliches Modell, uvm.
|
Senifor79
(Themenstarter)
Anmeldungsdatum: 22. Februar 2012
Beiträge: 415
|
Ok. Was meinst du mit zentraler (Web-)Service ? ... die Datenbank soll nur im Intranet laufen und ich wollte das MVC - Konzept anwenden. Würde mich also selbst um die Trennung von Modell, View und Controller kümmern.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
Lysander schrieb: Ganz kurz nur, weil ich heute keine Zeit mehr habe: Du solltest Dein Frontend nicht *direkt* auf die DB zugreifen lassen! Lass die Kommunikation mit der DB immer über einen zentralen (Web-)Service laufen. Das erhöht die Sicherheit und trägt dazu bei, Logik und GUI sauber zu trennen.
Vor allem erhöht es die Latenz. In der Allgemeinheit unterschreibe ich Deine Aussage nicht. Direkter Zugriff auf die DB (z.B. vermittelt durch JPA) ist eine völlig gängige Architektur.
Wenn viele Leute nur parallel lesen, wäre SQLite immer noch eine Option.
In diesem Fall eher nicht.
Ach weißt Du, Aussagen wie ich sie getätigt habe sind *immer* stark subjektiv und emotional. Schau Dir Postgres einfach mal an; es hat so viele Aspekte, die ich besser finde als bei MySQL. Schemata, besseren SQL-Standard, keine "Storage"-Engines, sondern *ein* einheitliches Modell, uvm.
Sehe ich auch so.
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
rklm schrieb: Vor allem erhöht es die Latenz. In der Allgemeinheit unterschreibe ich Deine Aussage nicht. Direkter Zugriff auf die DB (z.B. vermittelt durch JPA) ist eine völlig gängige Architektur.
PHP ist auch gängig - besser wird es dadurch nicht, oder? 😉
Natürlich kann man auch einen Smart-Client bauen, der alles von DB-Zugriff über Logik bis zur GUI vereint. Aber will man das heutzutage wirklich?
Wenn viele Leute nur parallel lesen, wäre SQLite immer noch eine Option.
In diesem Fall eher nicht.
Wie kommst Du darauf? Also ich habe bisher nur *einen* kurzen Satz über das Szenario gelesen... daraus konnte ich nicht ableiten, dass es da eine Server basierte DB braucht! (Es könnte sogar sein, dass eine relationale DB gar nicht der richtige Ansatz ist)
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
Lysander schrieb: rklm schrieb: Vor allem erhöht es die Latenz. In der Allgemeinheit unterschreibe ich Deine Aussage nicht. Direkter Zugriff auf die DB (z.B. vermittelt durch JPA) ist eine völlig gängige Architektur.
PHP ist auch gängig - besser wird es dadurch nicht, oder? 😉
Ich kann PHP nicht besonders gut beurteilen. Aber in JEE-Land ist es nicht nur gängig sondern sinnvoll so zu arbeiten. Abgesehen davon hast Du da ja auch mehrere verschiedene Layer für Präsentation, Geschäftslogik, Abstraktion der Datenquelle und dann der Datenbank. (Falls das Dein Grund für den zentralen Dienst ist.)
Natürlich kann man auch einen Smart-Client bauen, der alles von DB-Zugriff über Logik bis zur GUI vereint. Aber will man das heutzutage wirklich?
Warum nicht?
Wenn viele Leute nur parallel lesen, wäre SQLite immer noch eine Option.
In diesem Fall eher nicht.
Wie kommst Du darauf?
Senifor79 wollte die Berechtigungen der DB nutzen, um den Zugang zu regeln, wenn ich das richtig sehe.
Also ich habe bisher nur *einen* kurzen Satz über das Szenario gelesen... daraus konnte ich nicht ableiten, dass es da eine Server basierte DB braucht!
Aber Du wusstest schon, dass man "die Kommunikation mit der DB immer über einen zentralen (Web-)Service laufen" lassen soll. Dann musst Du das Argument mit der unklaren Anforderungslage in beide Richtungen anwenden. Ciao robert
|
Senifor79
(Themenstarter)
Anmeldungsdatum: 22. Februar 2012
Beiträge: 415
|
Moin,
Senifor79 wollte die Berechtigungen der DB nutzen, um den Zugang zu regeln, wenn ich das richtig sehe
Ja, genau. Ich möchte nicht, dass ein Nutzer, ob gewollt oder nicht, Tabellen löscht, oder auch Datensätze ....Tabellen schreiben dürfen, und dann wieder Nutzer die auch einfügen und löschen dürfen etc ... (ohne jetzt ein Use-Case-Diagramm zu veröffentlichen) und andere, die nur lesen können ... Natürlich kann man auch einen Smart-Client bauen, der alles von DB-Zugriff über Logik bis zur GUI vereint. Aber will man das heutzutage wirklich?
Was spräche dagegen ? Gruß, Senifor
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
rklm schrieb: Ich kann PHP nicht besonders gut beurteilen. Aber in JEE-Land ist es nicht nur gängig sondern sinnvoll so zu arbeiten.
Gerade in der Java-Welt ist man vom Desktop doch immer noch weit entfernt! Java hat sich auf dem Server etabliert; Desktop-Applikationen sind nach wie vor keine besondere Stärke von Java. Ok, mit JavaFX 8 könnte sich das langsam ändern. Webservices sind doch quasi ein Kind der Java-Welt.
Abgesehen davon hast Du da ja auch mehrere verschiedene Layer für Präsentation, Geschäftslogik, Abstraktion der Datenquelle und dann der Datenbank. (Falls das Dein Grund für den zentralen Dienst ist.)
Wenn man das wirklich konsequent durchzieht, ist das spätere Auswechseln von Komponenten ja auch recht einfach - die Gefahr ist natürlich groß, dass man da nicht gut trennt. Insbesondere zwischen Geschäftslogik und Präsentation wird oftmals gerne zu stark gekoppelt. Implementiert man das a priori als Webservice, so scheidet der Punkt sofort aus.
Warum nicht?
Z.B. wegen schwierigerem Deployment, weil man den Dienst auch auf Tablets o.ä. nutzen können möchte (da bietet sich eben eine Webapplikation an), weil man das / die Frontends später wechseln können möchte usw.
Senifor79 wollte die Berechtigungen der DB nutzen, um den Zugang zu regeln, wenn ich das richtig sehe.
Ok, dann wäre SQLite nicht geeignet.
Aber Du wusstest schon, dass man "die Kommunikation mit der DB immer über einen zentralen (Web-)Service laufen" lassen soll. Dann musst Du das Argument mit der unklaren Anforderungslage in beide Richtungen anwenden.
Touchee 😉 Ich bleibe aber dabei, dass eine indirekte Kommunikation mit der DB die Sicherheit Prinzip bedingt erhöht. Du kannst Verschlüsselung viel einfacher vornehmen als bei einer direkten Kommunikation und Du brauchst keine Passwörter außerhalb der Server-Umgebung zu deployen.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
Lysander schrieb: rklm schrieb:
Warum nicht?
Z.B. wegen schwierigerem Deployment, weil man den Dienst auch auf Tablets o.ä. nutzen können möchte (da bietet sich eben eine Webapplikation an), weil man das / die Frontends später wechseln können möchte usw.
Klar. Ich hatte aber Senifor79 so verstanden, dass er gerne eine Java-Anwendung schreiben wollte.
Ich bleibe aber dabei, dass eine indirekte Kommunikation mit der DB die Sicherheit Prinzip bedingt erhöht. Du kannst Verschlüsselung viel einfacher vornehmen als bei einer direkten Kommunikation und Du brauchst keine Passwörter außerhalb der Server-Umgebung zu deployen.
Muss man nicht. Wenn man einfach den DB-Account auch zur Authentifizierung nutzt, dann muss man nur das vom Nutzer eingegebene Passwort beim Verbindungsaufbau mit der DB an diese durchreichen. Und RDBMS stellen heutzutage auch Verschlüsselung der DB-Verbindung zur Verfügung. Es fragt sich natürlich, ob die Berechtigungen der Datenbank reichen, um die gewünschte Zugriffskontrolle herzustellen: die Berechtigungen greifen ja üblicherweise auf der Ebene von Schema-Objekten (also Tabellen, Sichten, Prozeduren usw.). Wenn man das zeilenbasiert machen will (also "Benutzer X darf nur einen Teil der Datensätze in Tabelle T sehen"), dann muss man entsprechende Views definieren und es könnte dann leicht eklig werden. Hängt alles davon ab. ☺
|