Hi,
SQL ist nicht viel mehr als eine Beschreibungssprache für den Export von Daten
. Die User fanden auf dem Web Daten zu erhalten noch immer besser als in den Großrechner ITs auf die Implementierung oder Erweiterung einer Businessfunktion zu waren. Damit nahm das große 'Übel' seinen Lauf.
Relationale Datenbanken wurden mit Hinblick auf 4 GL entwickelt und hernach meldet sich 3 GL zurück
.
DB hat von Grundidee her mit allem was heute unter Datenbank läuft eher wenig zu tun.
1) Jede
DB hat ihr eigenes File Format und bei manchen wird auch der Term On Disk Structure (zumeist gepaart mit Versionsnummer) verwendet um dieses zu konkretisieren.
Die relationalen Datenbanken wurden stark an Entity Relationship Modelling angepasst und diese Modellierungsmethoden dominierten im Business.
XBASE (DBASE,
Paradox usw.) hatten ein normiertes Format, aber die waren noch Record Server als Btrieve. Die Ursprünge der Nexus
DB gehen auf diese Tradition zurück (Flash Filer).
2) An sich hängt eine
DB nicht an Tabellen und selbst Tabellen resp. Sichten können physisch anders implementiert sein, allein war das bis 2k und hernach mit Web
DB (
MySQL usw...) kein Thema. Die objektorientierten DBs die waren zu krass. Aber langsam tritt der Aspekt wieder in den Vordergrund (Metadaten der Klassen usw... im Programm und nicht im Dictionary)
- Die Nexus DB kennt nicht nur ein BLOB sondern auch ein Bild.
- Die Oracle DB bildet das Dictionary als Tabelle ab, aber die darunter liegende phyische Implementierung dieser Tabelle ist eine andere.
- In Memory Tables wären so eine Sache
- Oracle Spatial Option
- Geodaten usw...
3) OO DBs bis ORM
- Eine Art von DB für solche eine Art von Anwendung waren in den 1990ern entweder Smalltalksysteme bspw. Gemstone (ins Smalltalksystem integriert oder Zugriff über Proxy Objekte) (alles auf fetten UNIX Hobeln) bspw. für CAD Systeme,
- Versant (Object Server) oder
- Objectstore (Page Server) als sehr bekannte Vertreter und eigentlich damals die Wahl für dich.
Es gibt einen Haufen OODBs die in Nischen genau die Thema Bilder oder 3D Zeichnungen zum Inhalt haben. Im Moment gebraucht solche systemischen Zugänge kaum einer mehr.
Die Synthese aus Entity Relationship Modelling und OO
DB (eigene Spracherweiterung bishin zu eigenen Standards S in
SQL wird zu OOQL) und ORM Bilbliotheken. Telerik ORM ist bspw. 'Versant'. Eine OO Datenbank speicherte bspw. Collections.
-
Obwohl sich viel konnten waren diese DBs mit Nachteilen behaftet
a) geschlossen
a1) Im Falle des Zugriffs über eine C-
API mussten bspw. im Falle von Versant Metadaten mittels eines Preprozessors ergänzt werden
b) allein mittels selbst implementierten Programmen zu administrieren und auch zu restrukturieren
c) Objektpersistenz und auch Versionierung (Zeitabhängigkeit wird im Hintergrund gemanaged)
d) ...
Mit 8.1 Oracle einfach das Thema gebügelt. Hinzu gesellten sich noch die User welche der Meinung waren, dass Sie die vollen
SQL Profis waren. Zur Zeit als es Stamm- und Bewegungsdaten 1:n mit kaum komplexen Zeitbezügen gab ...
Aus Delphi Sicht wäre für dich die Object Spider Database wohl das Pendant. Heute wäre das ein JSON ORM plus SQLLite.
Hallo,
Ich kenne zwar ein paar Namen der bekannteren Datenbanken wie
MySQL, SQLLite oder Firebird, würde aber gerne mehr darüber wissen wollen.
Ich habe ein paar ganz allgemeine Fragen zu Datenbanken:
1. In welchen Dateiformaten speichern Datenbanken ihre Daten?
SQL sollte zwar die Datenbanksprache sein, aber mit welchem Format werden die Daten eigentlich gespeichert?
2. Welche Dateiformate können in DBs gespeichert werden? Texte, Bilder, 3D-Objekte.. ist das alles ohne weiteres möglich?
3. Ich würde gerne unter anderem 3D-Objekte (Format ".stl") in einer
DB speichern. ich habe von jmd gehört, der diese in seiner "MongoDB" in JSON speichert. Ist das notwendig solche Objekte zu konvertieren oder ist das Speichern auch direkt als stl möglich?