SQL und Datenbanken | Alles von A bis Y(juq)

  • Formelle Begrüßung:

    Sehr geehrte Leserinnen und Leser,

    damit wäre das schon mal erledigt. Puh, ich hasse diese Stelle in jedem Text den ich verfasse...


    Das schlimmste was es für mich gibt! ^^


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    Einleitung:

    Da du deinen Weg hierher gefunden hast, bist du vermutlich an das Thema SQL oder auch Datenbanken allgemein interessiert. Nun, hierbei handelt es sich um eine (ausführliche) Tutorial-Reihe die sich mit folgenden Themen beschäftigt:

    - Was ist eine Datenbank?

    - Was ist SQL und wie funktioniert es?

    - Wie strukturiere ich eine Datenbank korrekt? Bzw. Wie baue ich sie auf?
    - Wie verwende ich diese in AutoIt?


    Im Großen und Ganzen beschäftige ich mich hier hauptsächlich mit SQL-Datenbanken, jedoch versuche ich möglichst viele Hintergrundinformationen mitzuliefern, um euch ein gutes Allgemeinbild über Datenbanken und SQL (und dessen Zusammenhang) zu hinterlassen.


    !!! Es sind keine Vorkenntnisse nötig !!!


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    Aufbau dieses Tutorials:

    Das Tutorial ist in 4 großen Abschnitten (einzelnen Beiträgen) verfasst. Die 4 einzelnen Abschnitte sollen nach und nach die oben genannten Fragen aufklären und entsprechend auf den nächsten Abschnitt vorbereiten. Es gibt sowohl theoretische, wie auch praktische Teile in diesem Tutorial. Kleinere Aufgaben entsprechend dann, wenn es meiner Meinung nach Sinn ergibt Dinge auszuprobieren.


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    1. Teil | Datenbanken

    In diesem Teil geht es grundsätzlich erst mal darum zu klären, was Datenbanken überhaupt sind und wann diese eingesetzt werden. Dabei gehe ich auf die verschiedenen Datenbanktypen ein und gebe euch einige Beispiele dazu. Auch der eine oder andere Beispielcode wird entsprechend zu finden sein. Das Hauptmerkmal der Tutorial-Reihe liegt allerdings speziell auf SQL-Datenbanken. Darum werden andere Datenbankformate hier eher angeschnitten.


    2. Teil | SQL & DBMS

    In diesem Teil klären wir dann entsprechend, was SQL ist und wie man es benutzt. SQL wird hauptsächlich (wen wundert es 8o) mit SQL-Datenbanken in Verbindung gebracht. Zudem erkläre ich auch, was ein Datenbankmanagement System (database management system - DBMS) ist und wie SQL-Datenbanken mit einem DBMS in Verbindung stehen.


    3. Teil | Datenbankentwicklung

    Eine Datenbank will gut durchdacht sein. Vor allem SQL-Datenbanken geben viele unterschiedliche Anwendungsmöglichkeiten was das Design und der Nutzung entspricht. In diesem Teil gehe ich näher darauf ein, wie man eine SQL-Datenbank entsprechend plant wenn man viele Daten sinnvoll speichern möchte.


    4. Teil | SQL-Datenbanken in AutoIt

    In diesem Abschnitt klären wir, wie wir das neue Wissen nun eigentlich in AutoIt umsetzen können. Eigentlich ist dieser Abschnitt dann keine Kunst mehr und erfordert nur die eine oder andere UDF und eine Handvoll an Funktionsaufrufe. Ich versuche hier nach Möglichkeit jede UDF einmal aufzulisten und vorzustellen die ich dazu finden kann.


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    Da ich das Tutorial gerade erst verfasse sind die 4 Platzhalter unter diesem Beitrag gerade leer. Dort findet ihr aber dann entsprechend das fertige Tutorial. Ich möchte zumindest heute noch den ersten Teil vollständig verfassen und im besten Fall bis morgen Abend dann fertig sein. Versprechen tue ich aber nichts! 8)


    So zur groben Zeitplanung... Vermutlich läuft es ehh daraus hinaus dass ich erst nächste Woche fertig bin weil ich viel zu viel schreibe... :/

  • 1. Teil | Datenbanken

    Wer bereits mit dem Begriff "Datenbank" vertraut ist, kann eigentlich diesen kompletten Teil überspringen. Dieser ganze Tutorial-Teil ist ziemlich theoretisch gehalten und liefert eigentlich nur reine Informationen. Lest euch die Abschnitte durch, die euch interessieren. Allerdings solltet ihr den Abschnitt, in dem es um SQL-Datenbanken geht nicht überspringen, wenn ihr mit dem Begriff nichts anfangen könnt.


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    Was ist eigentlich eine Datenbank?

    An dieser Stelle zitiere ich einfach mal aus dem Duden:

    elektronisches System, in dem große Bestände an Daten (2, 3) zentral gespeichert sind

    Im Prinzip kommt da alles in Frage. Sicher hast du schon mal die eine oder andere Excel Tabelle ausgefüllt, oder gar Informationen in eine Textdatei geschrieben. Das alles sind im Prinzip schon Datenbanken. Sie beinhalten Daten die weiter verarbeitet werden. Diese Daten können in diesen Dateien unterschiedlich formatiert und strukturiert sein. Eine Excel Tabelle ist eben eine Tabelle und in einer Text Datei nun mal eine Text Datei. Aber sie beinhalten Daten für irgendetwas, sei es für eine Software (wie Excel zur Anzeige) oder eben klar leserliche Informationen für den Menschen in einer Textdatei. Allerdings sind das nur die einfachsten Beispiele die mir einfallen. Interessanter wird es, wenn man sich überlegt wie man als Programmierer Daten so speichert, dass man sie im Programmcode einfach auslesen oder verändern kann.


    Viele Menschen und pfiffige Programmierer hatten sich schon bereits darüber den Kopf zerbrochen. Zum Glück gibt es schon vorgefertigte Strukturen die man für seine Daten in einer Datenbank nutzen kann, um die Weiterverarbeitung zu erleichtern. Einige dieser Datenbanktypen möchte ich dir hier einmal vorstellen. Zum Schluss kommen wir dann auf die SQL-Datenbank zu sprechen.


    Welcher Datenbanktyp nun für welche Applikation am sinnvollsten ist, muss jeder Programmierer jedoch selber entscheiden. Allerdings sind SQL-Datenbanken zu einem guten Drittel der meist genutzte Datenbanktyp weltweit. Gerade dadurch ist es als Programmierer sicherlich nicht verkehrt, sich einmal damit zu beschäftigen.


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    INI-Dateien

    Eine INI-Datei ist eigentlich kein Datenbankformat. Zumindest wurde es nicht dafür ausgelegt. Der Sinn hinter INI-Dateien bestand damals darin, eine einheitliche Struktur Vorgabe für Standardeinstellungen von Programmen oder des Betriebssystem zu geben. Jedoch bietet diese einfache Struktur in einer INI-Datei auch die Möglichkeit, einfache Daten zentral zu lagern und diese als Datenbank zu missbrauchen. Gerade durch die Built-In Funktionen von AutoIt werden INI-Dateien gerne mal als Datenbank genutzt, da es einen einfachen und unkomplizierten Zugriff auf diese erlaubt.


    Eine INI-Datei ist relativ einfach strukturiert. Sie beinhaltet einzelne Sektionen welche Daten logisch voneinander trennen kann. Die Daten selber werden an Zugriffs-Bezeichner gekoppelt. Das ganze sieht dann in etwa so aus:

    Code
    1. ; Das ist ein Kommentar
    2. [Sektion 1]
    3. Schlüssel_1 = Irgendwelche Daten
    4. Schlüssel_2 = Noch mehr Daten
    5. [Sektion 2]
    6. Schlüssel_1 = Daten
    7. Schlüssel_2 = usw...

    Der Vorteil bei dieser Art der Speicherung ist, dass man bestimmte Daten mit einem Schlüsselwort koppeln kann, um diese später wieder abzurufen. Gehen wir mal von einem Chatprogramm aus welches die Chatverläufe und die Zugangsdaten zentral auf einem Server speichert. Solch eine Datei könnte als INI-Datei folgendermaßen aussehen:


    Dies ist nur ein sehr einfaches Beispiel um das zu verdeutlichen. Ihr könnt die Daten ja mal unter "chat.ini" abspeichern und folgendes Skript testen:


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    CSV-Dateien

    Das CSV Dateiformat wurde damals geschaffen, um Tabellen-artige Strukturen in einer Datei abzuspeichern. Ein allgemeiner Standard existiert nicht und je nach Software können diese Dateien auch unterschiedlich interpretiert werden. Der Aufbau einer solchen Datei ist relativ einfach. Zeilen werden üblicherweise mit einem Zeilenumbruch getrennt und Spalten üblicherweise mit einem Komma. Ein Beispiel für eine Tabellen-artige Struktur könnte so aussehen:


    Montag Dienstag Mittwoch Donnerstag Freitag
    MAT KOM MAA
    ENG MAA ENG DAB
    BEN DAB DAB KOM BEN
    MAT


    Bei dem Beispiel handelt es sich um einen Stundenplan aus einer meiner Wochen im 6. Semester. Als CSV-Datei würde solch eine Tabelle folgendermaßen übersetzt:

    Code: data.csv
    1. Montag,Dienstag,Mittwoch,Donnerstag,Freitag
    2. ,MAT,KOM,,MAA
    3. ,ENG,MAA,ENG,DAB
    4. BEN,DAB,DAB,KOM,BEN
    5. MAT,,,,

    Du kannst die Datei einfach mal unter "data.csv" abspeichern und folgendes Skript ausprobieren:

    AutoIt: script.au3
    1. #include <Array.au3>
    2. #include <File.au3>
    3. Local $asTable
    4. _FileReadToArray("data.csv", $asTable, 0, ",")
    5. _ArrayDisplay($asTable)

    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    XML-Dateien

    2 kleinere Beispiele zu einfachen Datenbanken (und deren Verwendung in AutoIt) haben wir im Schnelldurchlauf mal angesprochen. Allerdings kommen wir jetzt mal zu weitaus komplexeren Strukturen da unsere Daten meist nicht immer so einfach strukturiert sind. Jedoch versucht XML mit relativ wenig an Regeln eine möglichst dynamische Datenstruktur zu ermöglichen. Was dies genau heißt wird in diesem Abschnitt noch anhand eines Beispiels klar. Aber vorab gehen wir einmal darauf ein wie eine XML-Datei nun eigentlich aufgebaut ist. Im Gegensatz zu INI- oder CSV-Dateien sind XML-Dateien entsprechend klar genormt und definiert. Wenn man seine XML-Dateien mit anderer Software kompatible halten möchte, sollte man sich auch an die vorgegebenen Richtlinien halten.


    In der ersten Zeile eines jeden XML-Dokumentes befindet sich normalerweise die Angabe, welche XML-Version und welche Zeichensatzkodierung im Dokument verwendet wird:

    <?xml version="1.0" encoding="UTF-8"?>


    Diese Angabe ist jedoch optional. Standardmäßig wird ansonsten von der neusten XML-Version und der Zeichensatzkodierung UTF-8 ausgegangen. Jedoch sollte diese Angabe immer gemacht werden, je nach Software könnte sonst ggf. von einer XML-Version ausgegangen werden, für welche die Daten in der Datei selber gar nicht ausgelegt sind. Die Daten könnten falsch interpretiert werden. Die Angabe macht also klar, nach welchen Richtlinien sich dieses Dokument hält. Es gibt noch mehr solcher Anweisungen die nach dieser folgen könnten. Allerdings reicht uns das für einen kleinen Einblick aus.


    Jedes XML-Dokument speichert seine Daten in Elementen. Ein Element beschreibt dabei einen Bezeichner der in < ... > gesetzt ist. Dieser Bezeichner wird auch hinterher wieder mit einem </ ... > geschlossen. Dies ist so ähnlich wie BB-Codes in Foren oder HTML-Elemente. Diese Elemente können verschachtelt werden. Alle anderen Elemente werden dabei in ein einzelnen, übergeordnetes Root-Element geschachtelt.


    Dies sind eigentlich die wichtigsten Regeln die es zu beachten gibt. Es gibt weitaus mehr, aber als kleiner Einblick dürfte das genügen. Ein Beispiel dürfte dafür eigentlich ausreichen um zu verstehen, was gemeint ist:

    XML
    1. <?xml version="1.0" encoding="UTF-8"?>
    2. <RootElement>
    3. <Element_1>Daten</Element_1>
    4. <Element_2>
    5. <Element_2_1>Noch mehr Daten</Element_2_1>
    6. <Element_2_2>usw...</Element_2_2>
    7. </Element_2>
    8. </RootElement>

    Schön, jetzt wissen wir also wie so ein Ding in etwa ausschaut. Doch was bringt uns nun das ganze? Gehen wir mal davon aus, dass wir in einer Firma arbeiten die irgendetwas herstellt. Nehmen wir mal an es handelt sich dabei um Schreibtische. Wir wollen sämtliche Materialien und die Einzelkosten in einer Datenbank hinterlegen, um die reinen Materialkosten von einer Software aus auszurechnen. Da Materialien hier in Deutschland genormt sind, speichern wir auch die Norm-Bezeichnung mit ab, um ggf. direkt auch aus der gleichen Datenbank eine Einkaufsliste zu generieren.


    Da dies jetzt nur ein Beispiel wird, werde ich sicher nicht die korrekten Norm-Bezeichnungen raussuchen. Stattdessen werde ich mir einfach welche ausdenken, genau wie die Preise...

    Ob es nun realistisch ist sei mal dahingestellt...


    Unser Schreibtisch hat eine Tischplatte in der Breite von 120cm und in der Länge von 60cm (DIN-T120x60). Die Kosten einer solchen Tischplatte liegen bei 15.99€. Der Schreibtisch hat an der rechten und linken Seite eine Holzplatte die als Seitenwand wie auch Tischbein fungiert. Sie ist 60cm Breit und 80cm Hoch (DIN-B60x80 - Kosten: 7.50€). Links unter der Tischplatte wird eine Schublade angebracht. Die Schublade besteht aus 5 Holzplatten alle 50cm Breit und 50cm Hoch (DIN-H50x50 - Kosten: 3.37€).


    Die Schrauben und den restlichen Krempel lasse ich mal aus. Wir benutzen Holzleim, der ist extrem billig und gibt und höchstens bei der verwendete Menge 0.01€ Aufschlag! 8)


    Okey, im Prinzip haben wir folgende Materialien:

    - 1x Tischplatte (DIN-T120x60): 15.99€

    - 2x Tischbein-platte (DIN-B60x80): 2x 7.50€

    - 5x Holzplatte (DIN-H50x50): 5x 3.37€


    Sieht noch simpel aus, aber nur weil wir den restlichen Krempel mal dezent übersprungen haben. Aber das dürfte uns als Beispiel genügen. Wir haben also als Endprodukt einen Schreibtisch der aus verschiedenen Materialien besteht:

    XML
    1. <?xml version="1.0" encoding="UTF-8"?>
    2. <Schreibtisch>
    3. </Schreibtisch>

    Der Schreibtisch selber besteht eigentlich aus 2 Komponenten, nämlich der Tisch selber und die Schublade:

    XML
    1. <?xml version="1.0" encoding="UTF-8"?>
    2. <Schreibtisch>
    3. <Tisch>
    4. </Tisch>
    5. <Schublade>
    6. </Schublade>
    7. </Schreibtisch>

    Der Tisch besteht aus den beiden Tischbein-platten und der Tischplatte selber. Diese einzelnen Materialien haben ihren eigenen Preis, die benötigte Stückzahl und die Norm-Bezeichnung:

    Aha! Da kommen wir der Sache doch schon etwas näher. Das sieht doch mal tatsächlich strukturiert aus. :love:


    Versuch mal selber die letzten Daten für die Schublade in einem Textdokument hinein zu schreiben. Deine Lösung kannst du dann mit meiner abgleichen:

    Die Datenbank steht und wie so ein XML-Dokument aussieht dürfte nun grob ersichtlich sein. Die Daten sind für den Menschen, aber auch für die Maschine leicht auszulesen. Zwei Fliegen mit einer Klappe! Wie einfach das nun funktioniert, zeige ich dir mal mit einem Beispielskript. Wir wollten nämlich daraus sowohl die Kosten, wie auch die Einkaufsliste generieren. :evil:


    Speichere die Datei im oberen Spoiler unter den Namen "table.xml" ab. Dann kannst du folgendes Skript ausprobieren:

    Das Schöne daran ist ja, dass ihr die Datenbank auch noch um Materialien einfach erweitern könnt. Klar ist mein Zugriff darauf doch schon sehr Fehleranfällig, vor allem wenn ihr Bezeichner verändert oder Informationen auslasst. Normalerweise greift man auch so nicht auf ein XML-Dokument zu und benutzt stattdessen das passende Framework. Allerdings soll dieses Beispiel einfach nur einmal verdeutlichen, dass wir mit XML-Dokumenten einige Freiheiten genießen und nicht so eingeschränkt sind wie bei INI- oder CSV-Dateien. Vielleicht noch ein anderes Beispiel. Vielleicht wollt ihr einfach nur die Kosten und die Einkaufsliste ohne die Schublade berechnen. Das würde dann so aussehen:

    Analog dazu könnt ihr auch nur die Schublade ausrechnen. Ich denke es ist nun ziemlich klar, dass ihr aus einer solch einfachen Strukturierung schon bereits Daten für die verschiedensten Zwecke auslesen könnt. Das XML-Dateiformat würde ich jedem zusätzlich zu SQL ans Herz legen, der sich Gedanken über Datenspeicherung macht.


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    Weiteres folgt...

  • Teil 1 | SQL-Datenbank

    Vielleicht hast du den oberen Abschnitt bis hier hin übersprungen. Vielleicht hast du ihn auch gelesen. Nun denn, kommen wir zu den wichtigsten Abschnitt in diesem Teil, der SQL-Datenbank. In den vorherigen Abschnitten dieses Tutorial Teil habe ich erläutert, was eine Datenbank im allgemeinen ist. Im Grunde habe ich damit schon die Hälfte einer SQL-Datenbank erklärt. Wie auch in andere Datenbanktypen, werden die Daten in einer SQL-Datenbank strukturiert. Allerdings ist diese Struktur leider nicht so einfach erklärt wie eine INI-Datei, eine CSV-Datei oder eines XML-Dokuments. Tatsächlich sind die Dateien, welche die Daten beinhaltet ziemlich schwierig für einen Menschen zu lesen und zu entziffern. Da SQL-Datenbanken sich stetig entwickelt haben und die Anforderungen stiegen, hat man sich Gedanken darüber gemacht wie man mehrere Zehntausende an Daten (was nicht mal so unüblich ist) effektiv und effizient speichert. Dabei soll eine SQL-Datenbank mehrere Anforderungen erfüllen.


    Das Schreiben und Lesen einer Datei erfordert für den Computer Zeit. Bei kleinen Datenmengen ist diese benötigte Zeit kaum merkbar. Aber sobald viele Daten schnell verarbeitet werden sollen, kann eine ineffiziente Programmierung einen Unterschied von mehreren Minuten machen. Zum Glück müssen wir uns gar nicht um die Strukturierung und den Zugriff auf eine SQL-Datenbank Gedanken machen. Es gibt bereits Software welche genau diesen Zugriff für uns regelt und entsprechend optimiert wurde. Die Daten einer SQL-Datenbank sind meistens nicht in einer einzelnen, sondern viele kleine Dateien verteilt. Der Hintergrund dazu ist, das man so möglichst wenig Zeit für den Zugriff auf die Dateien benötigt. Das Lesen und Schreiben auf einer Festplatte dauert in der Regel länger, wenn die Datei ziemlich groß ist. Aber das ist ein anderes Thema und nicht Teil dieses Tutorials. Im zweiten Teil gehe ich dann näher darauf ein, wie man nun auf eine SQL-Datenbank zugreift und was deren Vorteile sind.


    Nun gut, das Wichtigste ist bisher erwähnt. Aber schauen wir uns einmal an, welche Grundidee hinter einer SQL-Datenbank steckt und wie diese aufgebaut ist.


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    Im Prinzip sind SQL-Datenbanken von ihrer inneren Struktur ziemlich simpel gehalten. Dabei handelt es sich um eine Datenstruktur, welche die Daten tabellarisch auflistet. Wenn man sich mal überlegt wie man seine Daten in einer Software abspeichert, sind die meisten Strukturen wohl einer Tabelle ähnlich. Diese ist für den Menschen am einfachsten zu handhaben und bietet viele Möglichkeiten. Aber wäre eine SQL-Datenbank einfach nur eine einfache Tabelle, wäre ein komplettes Tutorial darüber ja ziemlich sinnlos. Allerdings halten wir erst einmal fest, dass SQL-Datenbanken im Grundkonzept nur Tabellen sind.


    Allerdings wurden SQL-Datenbanken dafür entworfen, möglichst viele Anwendungsbereiche abzudecken. Sie soll als erste Wahl dienen, wenn wir viele Daten effektiv speichern und verarbeiten wollen. Viele unterschiedliche Firmen und Anwendungen arbeiten mit dieser Art von Datenbank. Die Daten sind tabellarisch gut für den Menschen lesbar und in einer Software einfach zu verarbeiten. Das man sich eine SQL-Datenbank allgemein als Tabelle vorstellen kann, ergibt dann entsprechend Sinn.



    Allerdings kann eine SQL-Datenbank noch einige Dinge mehr als nur einfach die Daten tabellarisch zu strukturieren. Meist hat man, der Übersichtlichkeit wegen, mehrere Tabellen. Jede Tabelle beinhaltet ihre eigenen Daten die logisch zusammen gehören. Als Beispiel gehen wir mal von einer Firma aus, die Waren einkauft, verarbeitet und dann verkauft. Sämtliche Verwaltungen von interessante Daten für solch eine Firma, werden gespeichert. Solche Daten könnten Beispielsweise eine Mitarbeiter-Liste sein, wo dann Daten wie Geburtstag, Wohnort und das Gehalt hinterlegt sind. Andere Daten können dann die Kosten von den Rohstoffen für die Weiterverarbeitung sein (mit den bevorzugten Firmen welche diese Rohstoffe für geringe Preise herstellt). Eine andere Tabelle könnte sämtliche Einnahmen und Ausgaben beinhalten um am Monatsende eine Bilanz ziehen zu können. Und und und,... Es gibt in einen Betrieb viele wichtige Daten auf die man gerne einen schnellen und einfachen Zugriff haben möchte, um alles auf einen Blick zu haben.


    Trotz den verschiedenen Tabellen, hängen die Daten alle miteinander zusammen. Sie gehören alle der selben Firma die sie für unterschiedlichste Zwecke benötigt. Einige dieser Tabellen verweisen dann vielleicht auf Einträge von anderen Tabellen, um doppelte Daten auszuschließen und die Tabellen miteinander zu referenzieren. Ein einfaches Beispiel soll dies verdeutlichen:


    Gehen wir von einer Tabelle für einen Online-Shop aus, welche die Login-Daten von ihren Benutzern beinhaltet:

    Benutzer Passwort
    Schnuffel123 apfel
    Petra69 honig
    Superschlau passwort


    Eine andere Tabelle beinhaltet dann entsprechend Informationen darüber, welche Artikel sich im Sortiment befinden:

    Artikel Preis
    Schuhe 12.99€
    Waschmaschine 300.00€
    Teller 3.58€


    Eine andere Tabelle kann nun Beispielsweise die getätigten Einkäufe beinhalten, die jeder Benutzer getätigt hat:

    Benutzer Artikel
    Schnuffel123 Schuhe
    Schnuffel123 Waschmaschine
    Petra69 Schuhe
    Petra69 Teller
    Superschlau Waschmaschine
    Superschlau Teller


    Und noch mehr Daten könnten so gespeichert sein. Wie man sicherlich sehen kann, hängen die Daten miteinander zusammen aber sind logisch voneinander getrennt. Möchte man nun wissen wie viele Schuhe verkauft wurden wie hoch die Einnahmen dadurch waren, geht man die getätigten Einkäufe durch und zählt die Anzahl der verkauften Schuhe. Danach guckt man in die Tabelle für die Preise, sucht den Preis heraus und mit ein wenig Mathematik kommen wir auf 25.98€ Einnahmen durch die Schuhe.


    Natürlich werden solche Dinge entsprechend von einer Software übernommen, aber ich denke es ist nun klar dass eine tabellarische Struktur allgemein für viele verschiedene Dinge eingesetzt werden kann. Aus diesem Grund ist auch die Grundidee der SQL-Datenbank, die Daten tabellarisch zu behandeln.


    ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


    Aufgrund der Zeichenanzahl im Forum (20'000 Zeichen) bin ich leider doch gezwungen mehr Beiträge zu verfassen, als die bis dato. geplanten 4. Mal schauen wie ich das organisieren. Weiteres folgt... xd