Allgemeine Amateurfrage zu DBs

[mkinzler]

Zitat:

Noch eine Anmerkung zum Speichern der 3D-Objekte als JSON: Diese würden dann auch nicht als normaler Text in der Datenbank gespeichert (wo normalerweise nach 255 Zeichen Schluss ist bzw. bei Oracle nach 4.000 Zeichen), sondern als CLOB.

Auch das hängt vom DBMS ab.

[MichaelT]

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.

Zitat von derseitzer:

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?

[derseitzer]

Zitat:

Eine Empfehlung für eine DB (oder was anderes) kannst Du hier aber nur dann erhalten, wenn Du mehr Informationen über dein Wunschprojekt lieferst...

Dann gehe ich mal auf das Angebot ein und sage: Ich würde gerne Meta-Daten wie Name, Position, Rotation, Skalierbarkeit, Pfad, Material (Farbe, Transparenz) in einer DB speichern. Die Daten werden dann in Browserapplikationen und 3D-Programmen (Unity) benötigt. Ich denke es kommen wahrscheinlich alle DBs in Frage oder liege ich da falsch (ich meine damit, das wahrscheinlich jede DB so etwas kann)

[jobo]

Für STL Files gibt es binäre und ASCII Varianten. Binär ist komprimiertes ASCII und enthält offenbar sowohl Daten (Vertices) als auch Anweisungen (gemäß einer 3D Konstruktion). Diese Daten willst Du nativ (ASCII) wahrscheinlich nicht in der DB speichern, auch nicht um sie direkt zu durchsuchen "Ich suche einen Vektor mit den Dimensionen ..."?!

Sowohl die ASCII- als auch die Binärvariante eines 3D Objekts würde man wie sagt in Blobs ablegen.

Du möchtest zu diesen Objekten Zusatzinformationen mitgeben, dafür kann man eine Datenbank nehmen und von dort aus, das STL File oder eine Binärform des Objekts in einem Datenbank BLOB Feld referenzieren.
Deine Metainformationen kann man natürlich in einer DB prima durchsuchen (per SQL) und erhält dann jeweils Links oder Referenzen auf das /die zugehörigen Objekte.

Welche DB ist dabei egal, außer man achtet auf Kosten, Leistungsfähigkeit, Fußabdruck, Plattformunabhängigkeit usw.