Allgemeine Amateurfrage zu DBs

[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?

[DieDolly]

Zitat:

2. Welche Dateiformate können in DBs gespeichert werden? Texte, Bilder, 3D-Objekte.. ist das alles ohne weiteres möglich?

Sowas speichert man als BLOB würde ich sagen.

Große Dateien würde ich gar nicht erst in eine Datenbank speichern. Im besten Fall speichert man die Datei auf dem Dateisystem ab und hat in der Datenbank einen Verweis zur Datei.

[Luckie]

Zu Punkt eins: Das kann dir egal sein, deswegen gibt es ja SQL, damit es keine Rolle spielt, wie die Datenbank die Daten speichert.

[derseitzer]

Ok danke erstmal. Ich werfe hier mal eine weitere Frage in den Raum:
3D-Objekte sollten doch ebenfalls im SAP gespeichert werden können, wenn ich mich recht entsinne.
Wäre das als Speicher für die 3D-Objekte besser geeignet?

[Jasocul]

Zitat:

Zitat von derseitzer (Beitrag 1453005)

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?

Die Datenbank speicher die Daten in einem eigenen Format.
Aber ich denke, du meinst, ob man Datentypen hat. Ja, die hat man. Du kannst Zahlen- und Text-Formate nutzen. Es gibt auch noch CLOB und BLOB, was für deinen Fall relevant ist. BLOB steht für Binary Large OBject. Da kannst du eigentlich alles drin ablegen. Allerdings ist die maximale Größe bei den Datenbanken unterschiedlich.

Zitat:

Zitat von derseitzer (Beitrag 1453005)

2. Welche Dateiformate können in DBs gespeichert werden? Texte, Bilder, 3D-Objekte.. ist das alles ohne weiteres möglich?

Ohne weiteres nicht. Meistens muss da noch etwas Code eingebaut werden. Aber der Aufwand hält sich aber sehr in Grenzen. In BLOB geht notfalls alles rein, sofern die maximale Größe nicht überschritten wird.

Zitat:

Zitat von derseitzer (Beitrag 1453005)

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?

Man kann vieles machen, auch Daten vorher umwandeln. Notwendig ist das in der Regel nicht.
Es ist auch möglich, so vorzugehen, wie DieDolly das beschrieben hat. Das erfordert aber unter Umständen zusätzlichen Aufwand, da bei dem Verfahren die Dateien verändert, verschoben oder gelöscht werden könnten. Das bekommt dann die Datenbank, bzw. die Anwendung nicht mit.
Ob man es in der DB oder extern speichern, darüber kann man lange und ausführlich diskutieren. Beides hat Vor- und Nachteile.

[mkinzler]

Zitat:

1. In welchen Dateiformaten speichern Datenbanken ihre Daten? SQL sollte zwar die Datenbanksprache sein, aber mit welchem Format werden die Daten eigentlich gespeichert?

Die Implementierung erfolgt Systemspezifisch (DBMS).

Zitat:

2. Welche Dateiformate können in DBs gespeichert werden? Texte, Bilder, 3D-Objekte.. ist das alles ohne weiteres möglich?

In BLOB verpackt ist alles möglich. Nur dann verwendet man das DBMS nur als Speichersystem und nutzt somit die Vorteile nur bedingt.

Zitat:

Große Dateien würde ich gar nicht erst in eine Datenbank speichern. Im besten Fall speichert man die Datei auf dem Dateisystem ab und hat in der Datenbank einen Verweis zur Datei.

Das kommt darauf an. Eine Speicherung in der Datenbank kann sinnvoll sein oder nicht, je nachdem welches DBMS man einsetzt und was man bezweckt.

Zitat:

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?

In einen BLOB ja.
Dann nutzt man die Vorteile eines DBMS aber nicht.

https://pdfs.semanticscholar.org/689...96fcac5c69.pdf

[derseitzer]

Danke für die vielen Antworten. So wie ich das verstanden hab, macht eine DB also nur bedingt Sinn.
Wenn ich nun Programme schreibe, die z.B. beim Start automatisch 3D-Objekte hochladen sollen, wäre es
dann nicht sinnvoller eine DB für diese Objekte zu haben? Wie finde ich die beste DB für mein
Vorhaben? Sollte ich vor allem auf die maximale Speichergröße schauen?

Edit: Das Konvertieren zu JSON macht also schon relativ viel Sinn, so wie ich das verstanden habe, da somit keine Blobs verwendet werden müssen und die DB gut genutzt werden kann.

[hoika]

Hallo,

Zitat:

und die DB gut genutzt werden kann

Wenn Du direkt im JSON suchen willst, OK ...
Das erschließt sich mir gerade nicht.

Was außer Acht gelassen wurde, sind die Rechte in der DB.
Das kann ja nach DB sehr feingranular (schönes Wort ;) ) gesetzt werden.
Wenn die Datei im Dateisystem liegt und ein Link in der DB steht,
muss der jeweilige Nutzer auch die entsprechenden Rechte im Dateisystem haben.
Und wenn es ein Server ist, müssen die Freigaben für alle Nutzer gleich sein (z.B. Z:\)

Es hat alles Vor- und Nachteile.
Das musst Du abwägen.

[Lemmy]

Zitat:

Zitat von derseitzer (Beitrag 1453014)

Danke für die vielen Antworten. So wie ich das verstanden hab, macht eine DB also nur bedingt Sinn.
Wenn ich nun Programme schreibe, die z.B. beim Start automatisch 3D-Objekte hochladen sollen, wäre es
dann nicht sinnvoller eine DB für diese Objekte zu haben?

nein, dann wäre es sinnvoll, dass das Programm die Objekte korrekt hochlädt. Per FTP, REST Aufruf, je nach Anforderung halt.

Wenn die Frage noch dazu kommt wo das Programm die Objekte her bekommt, da könnte(!) dann eine Datenbank mit ins Spiel kommen. Eine Empfehlung für eine DB (oder was anderes) kannst Du hier aber nur dann erhalten, wenn Du mehr Informationen über dein Wunschprojekt lieferst... ;-)

[philipp.hofmann]

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.

[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 :-D. 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 :-D.

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:

Zitat von derseitzer (Beitrag 1453005)

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.