Eigene Datenbank?

[bigmama]

Hallo Leute, ich besuche momentan ein Berufskolleg, welches zum Abschluss ein eigenes Projekt verlangt.#

Ich habb lange überlegt und bin zum entschluss gekommen,d ass ne eigene Datenbank eigentlich mal was cooles wäre, aber dazu sei mal gesagt:

WAS genau ist eine Datenbank, welche anforderungen sollte sie erfüllen?
Ich hab mal nen Prog mit ODBC geschrieben und mit php im gebiet mysql programmiert bzw. gescriptet.

Aber wenn ich ne eigene DB schreiben will, WAS ann man sich darunter vorstellen.

Eine Datenbank sollte Daten speichern, aber wie? kann mir jemand mit ellgeimein verständnis helfen?

Wenn ich nicht weis was zu coden ist, kann ich es auch nicht...
Bin um jeden Beitrag Dankbar, greetz BigMama

[Unix-Tom]

Eine Datenbank sind IMHO die Files wo die Daten gespeichert werden.
Je nach Datenbank unterschiedliche Formate und speicherstructuren.

Ein DBMS (Datenbank Management System) ist die Schnittstelle zw. einer Datenbank und dem User.
Das DBMS kümmert sich um die Umsetzung der ein und ausgaben, Konsistenz der Daten und um vieles mehr. Würde jetzt zu weit das hier zu schreiben.

Wenn du nicht wirklich Programmieren kannst solltest du ein anderes Project wählen außer du möchtest nur etwas kleines schreiben. Aber auch das wird komplex.
Ich glaube SQLLITE nennt sich die DB mit DBMS. Kannst dir das ja mal ansehen.
Gibt in Rund um einige Beiträge in letzter Zeit

[bigmama]

1. IMHO? was soll das genau sein? Textdatei mit einer bestimmten Struktur?
2.ich kann einiger maßen programmieren, das projekt sollte aber trotzdem keine alzugroßen dimensionen einnehmen,wäre das einigermaßen realisierbar?

[peterchen]

IMHO == In My Humble Opinion == Meiner bescheidenen Meinung nach

Gibt verschiedene Datenbanksysteme, relevant sind zu zeit eigentlich nir Relationale (Tabellenorientiert, mit beziehungen zwischen Spalten), und Objektorientierte (die versuchen den Erfolg Relationaler Datenbanken an eine OO Schnittstelle anpassen)

Grundanforderung an eine Datenbank is sicherlich, eine Untermenge der gespeicherten Daten nach bestimmten Kriterien auszuwählen und der Anwendung zur Verfügung zu stellen, und bei der Veränderung der Daten Integritätsbedingungen zu prüfen. Das alles natürlich möglichst effizient.

Wichtige Features relationaler Datenbanken:

* Datenspeicherung in Tabellen
* Pro Tabellenspalte können Eigenschaften (Datentyp, "Wert einmalig in dieser Tabelle", ...) festgelegt werden
* SQL als "Standard-Sprache" zur Formulierung von Abfragen und Änderungsaufforderungen
* Abfrage kann man bestimmte Spalten auswählen (z.B. "name, Alter")
* Abfrage kann bestimmte Zeilen auswählen (nur die Zeilen mit "Alter<21")
* Tabellen können verknüpft werden (Hat man z.B. eine Tabelle für Wohnorte, und eine Tabelle für Personen - z.B. "Alle Wohnorte, wo jemand wohnt der jünger als 21 ist")
* Sortieren, Gruppieren der Ergebnisse

Natürlich noch technische features - z.B. werden Spalten, in denen oft gesucht/sortiert wird, normalerweise mit einem Sortierindex versehen.

Ein SQL-Tutorial ist sicher ein guter Einstieg.

Ein interessantes Projekt wäre z.B. eine "in-memory-DB", d.h. eine relationale Datenspeicherung, die ohne (explizite) externe Speichermedien auskommt.

Bei der Implementation müßte man sicherlich auf "beliebige" Datentypen, flexible Integration (d.h. minimale Anforderungen an den Client) achten, und evtl. nicht ganz so wild mit Speicher umgehen wie das Datenbanken sonst (zugunsten einer höheren Geschwindigkeit) tun. Sicher sollte man sich vorher feste Grenzen setzen, damit das ganze nicht ausufert (den ganzen SQL-Sprachufang zu implementieren wäre sicher vermessen)

"Projektfeatures" wären dann:
- Verwalten einer komplexen Datenstruktur
- Bereitstellen einer komfortabel zu verwendenen und einfach zu erweiternden Schnittstelle
- Textparsing (SQL)

[alex-t]

wie unix-tom weiter oben bereits angesprochen hat ist SQLite ein projekt welches einem jeden zeigt, was hinter einem dbms steckt.

SQLite ist allerdings etwas anderes als z.b. MySQL o.ä. DBMS
es gibt einige technische unterschiede, die hier alleine aufzuzählen den rahmen sprengen würde. deshalb fasse ich mich nur kurz:

sqlite ist ein lokales dbms. sqlite programmiertechnisch eine bibliothek - eine einzige dll. die daten werden in seperaten dateien gespeichert, die vom user ausgewählt werden.

zwar gibt es auch von systemen wie mysql embeded gegenstücke, die ähnlich zu bedienen sind, allerdings wiederrum lizenspflichtig sind. und meistens nutzt man bei solchen systemen die hauptanwendung, die wäre: ein server (lauffähig als dienst/daemon) an den man sich über das netzwerk einloggen kann. man hat praktisch eine schnittstelle in seinem programm (z.b. mysql++) die einen connect zu einem host erlaubt.

wer eine datenbank nur von einem client aus nutzt, oder die datenbank schnell und unkompliziert transportabel halten möchte bekommt von mir den tipp sqlite eine chance zu geben. wer allerdings zu verschiedenen datenbanken und/oder zu datenbanken in einem netzwerk connecten möchte, ist mit mysql und co. besser beraten.

sqlite ist meiner meinung nach perfekt an den stand alone einsatz angepasst. diese vorteile sind gleichzeitig nachteile grosser dbms wie mysql. umgekehrt ist auch das verhältnis der nachteile.

sqlite trägt nicht so viel codelast und reduziert sich auch auf das nötigste. es bietet zwei abfrage möglichkeiten. mit und ohne callbackfunktionen. wobei man sich jetzt darüber streiten kann ob man ein abfrageverfahren zu gunsten der performance kürzen könnte. ein weiterer +. wäre imho die möglichkeit bestimmte queries zu compilieren. damit würden sich die zeiten von statische abfragen aus grossen tabellen drastisch reduzieren. zumindest von der dokumentation dieser exp funktion war ich bis jetzt begeistert, da man gerade in kleineren lokalen anwendungen viele vorteile davon erwarten könnte.

sicherlich stösst sqlite irgendwann an die grenzen, wobei systeme wie mysql dort gerade erst mit ihren vorteilen anfangen können. jedoch sollte man bedenken, das licht schatten verursacht. mysql oder diverse microsoft db lösungen über odbc sind deutlich langsamer, wenn es darum geht im offline bereich grosse aber unkomplizierte db zu verwalten. allerdings bietet sqlite keine netzwerkunterstützung und ist somit nur eine freude, solange man die datenbanken auf einem rechner hat.

an sqlite wird noch weitergearbeitet und ich hoffe ich werde mich auch selbst irgendwann im stande sehen selbst beiträge zu diesem tollen projekt zu machen. es gibt dort nämlich kleinigkeiten, die bei manch anderen systemen bereits besser gelöst worden sind. z.b. multiuser funktionen. mehrere clients an der selben datenbank. zwar bietet sqlite bereits schon die grundlage für die multiuser funktion, aber es fehlt die nötige api, die dem user die arbeit abnimmt. mysql z.b. kümmert sich selbst darum, ob ein anderer thread bereits auf die datenbank zugreift, und wenn ja, wartet mysql mit der ausführung des queries. bei sqlite muss der benutzer - wenn weiss, dass seine mt anwendung möglicherweise simultan zugreifen wird - versuchen seine queries in einer schleife abzusetzen und als bedingung die prüfung nach einem lock der db file anführen. ausserdem fehlt imho ein lock auf einzelne tabellen und einzelne rows. hier gibt es glaube ich noch nicht einmal vorbereitungen.

falls irgendjemand mehr zum thema sqlite erfahren möchte, sollte er/sie sich meinen beitrag zum sqlite projekt anschauen und bei interesse vielleicht auch kontakt zu mir aufnehmen.