AW: Allgemeine Amateurfrage zu DBs
Zitat:
|
AW: Allgemeine Amateurfrage zu DBs
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)
3) OO DBs bis ORM
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:
|
AW: Allgemeine Amateurfrage zu DBs
Zitat:
|
AW: Allgemeine Amateurfrage zu DBs
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:10 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz