SQL Knowhow

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13137
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

SQL Knowhow

Beitrag von Jan » Sa, 19. Mär 2011 10:04

Kennt jemand von Euch sich wirklich gut mit SQL aus? Und kennt die praktischen Unterschiede zwischen DB...() und SQL?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

georg
Foren-Administrator
Foren-Administrator
Beiträge: 2243
Registriert: Fr, 08. Feb 2008 21:29

Re: SQL Knowhow

Beitrag von georg » Sa, 19. Mär 2011 20:54

Hallo, Jan -


ja und nein.

Was ist Deine Frage?

Ausserdem ist SQL nicht SQL, das ist wie mit ANSI-Cobol '85 und ANSI-Cobol '85.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.

Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Re: SQL Knowhow

Beitrag von Alfred » So, 20. Mär 2011 19:41

Hallo Jan,

ich denke ich kann mit viel praktischer Erfahrung dienen.

SQL ist eigentlich genormt.

Nur ist dieser Befehlssatz sehr beschränkt, so dass jeder Datenbankhersteller seine
eignen Ergänzungen vornimmt und die Unterschiede manchmal nur sehr marginal sind
und man viel Zeit mit der Suche nach dem Unterschied verbringt, da die Abweichung
vom Standard nicht offen gelegt wird.

SQL -Wikipedia gibt das sehr schön wieder.
Auch der dort angeführte Einzelnachweis "Die SQL-Norm als PDF" ist sehr informativ.

In der Praxis kommt es dazu, dass manche DB-Werkzeuge mehr können als der Datenbank-
hersteller vorsieht. Mir z.B. mit Firebird und IBExpert passiert.

Das Chaos erhöht sich durch die unterschiedliche Verwendung von Hochkommas ('') oder ("").

Zusätzliche Datentypen und Zeichensätze gegenüber dem Standard nerven ungemein.

Der simple Vorgang der Kopie einer Tabelle gerät in der Praxis zum Alptraum, da SQL so etwas
nicht vorsieht.

Die unterschiedlichen Ausgestaltung der Zugriffsschnittstellen der Datenbanken sorgen ebenfalls
für viel Verwirrung.

Die ständigen Updates mancher DB-Herstellen sorgen zudem für erheblichen Zusatzaufwand.

Das eingesezte Betriebssystem(Windows oder Linux(Samba in verschiedenen Ausprägungen)) auf
dem die Datenbank läuft sorgt ebenfalls für Ärger, den man zunächst nicht sofort diesem zuordnet.

Gruß
Alfred

Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Re: SQL Knowhow

Beitrag von Alfred » So, 20. Mär 2011 23:42

Alles was ich hier schreibe ist auf der Basis von Firebird. Aber keine Angst, die beiden
unterscheiden sich in den Grundlagen nur sehr wenig.

Zunächst möchte ich darauf hinweisen, dass mir der Ansatz von Arctica nicht klar ist.

Wie komme ich zu dieser Aussage?

Zunächst möchte ich beschreiben wie ich in der Praxis vorgehe:

Zunächst ist eine Datenbank auf dem Server anzulegen(Dies ist derzeit meines Wissens
nicht per Anwendungsprogramm realisierbar(Stichwort Zugriffsrechte)). Dies erfolgt in
der Regel auf dem Server mit einem speziellen Tool, dass für den Datenbanktyp ge-
schrieben worden ist.

Die erforderlichen Tabellen lege ich bereits auch in diesem Arbeitsgang an,
da das Anlegen einer Tabelle per Programm sehr aufwendig und fehleranfällig ist.
Wichtig bei diesem Arbeitsgang ist, das ein Feld als Primarykey angelegt wird.
Ohne diesem ist ein update der Daten bei den meisten Datenbanken nicht möglich.
Wenn ein eindeutiges Feld sich nicht aus der Anwendung ergibt, wird ein Feld an-
gelegt, dass eine fortlaufende Nummer erhält.

Im Programm wird dann über mehrere Parameter die Datenbank geöffnet.
Übergeben werden Servertyp(z.B. Firebird), User Name, Passwort des Users,
Typ des SQL-Dialects, IP-Adresse des Servers, Port des Firebird-Servers und das
Verzeichnis wo die Datenbank liegt. Beim Verzeichnis gibt es bereits das Problem,
dass man bei einem Linuxserver das Verzeichnis in der Linuxkonvention übergeben muss.

Wenn alles richtig ist sollte der connected auf true stehen.

Danach ist man in der Lage z.B. mit

Select * from Tabelle1 order by Feld1 where Kundname = "Langer"

auf die Daten zuzugreifen. Dieser simple Befehl ist letztendlich das Kernstück der Arbeit.

Die Daten kommen in das Datagrid, in dem man dem Datagrid die Datasource zuweist.

Ob und wann die Daten in der Tabelle1 dann geändert werden bestimmt man in der
Regel im Datagrid. Also muss dieses ziemlich komfortabel sein.

Das Arbeiten mit einer SQL-Datenbank unterscheidet sich also wesentlich von dem
Arbeiten mit einer DBF.

Mir ist also nicht klar wie man den Zugriff auf eine SQL-Datenbank mit reinen dbase-Befehlen
abdecken möchte, da hier 2 völlig verschiedene Gedankenwelten vorliegen.
Auch Foxpro bedient sich von Anfang an eines eigenen Select * Befehles.

Gruß
Alfred

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7331
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: SQL Knowhow

Beitrag von Tom » Mo, 21. Mär 2011 9:10

Hallo, Alfred.

Das Prinzip von Arctica soll, vereinfacht gesagt, darin bestehen, eine DBE zu liefern, die datensatzorientierte Kommandos (Skip, Append, Locate, Seek usw.) so umsetzt, dass sie eine SQL-Datenbank (in diesem Fall PostGre) "bedienen" können, ohne dass der Code der datensatzorientierten Applikation großartig überarbeitet werden muss.

Selbstverständlich kann eine Anwendung SQL-Datenbanken und -Tabellen anlegen; dafür muss man keineswegs auf dem Server/im Server arbeiten. Ich mache das längst - und seit Jahren - mit SQLExpress. Für die "native" Nutzung von SQL sollte man das Prinzip des "Cursors" (Current Record Set) verstehen - SELECT-Statements liefern im Normalfall keine Datensätze zurück, sondern eine Teilmenge der Datenbank, also im Prinzip einen Snapshot. SQL wertet aus (daher auch der Name - "Query" bedeutet "Abfrage". Man kann natürlich auch auf "lebendigen" Daten arbeiten, aber das Grundkonzept von SQL ist an dieser Stelle ein anderes.

Ein weiteres sehr wichtiges Konzept sind die "Stored Procedures", also Funktionen, die in SQL programmiert sind und auf dem/im Server gespeichert werden. Diese werden, wenn ich das richtig verstanden habe, auch in Artica besondere Bedeutung haben. Stored Procedures sind Code, der auf dem Server ausgeführt wird. Sie ermöglichen kompakte und praktisch lastfreie Abfragen, die vorgefertigt auf dem Server zur Verfügung stehen.

Ansonsten ist SQL prinzipiell relativ simpel. Nur eben völlig anders als das, was wir standardmäßig in unseren Apps tun.
Herzlich,
Tom

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14590
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: SQL Knowhow

Beitrag von brandelh » Mo, 21. Mär 2011 10:36

Hi,

wenn man einen DUMP (Datensicherung) mit Anlegen der Datenstruktur in z.B. MySql-Admin anlegt,
erhält man eine Textdatei mit allen SQL Anweisungen um genau die gesicherte Datenbank zu erzeugen.
Wenn man das nutzt, kann man daraus leicht die Befehlskette für andere Anwendungen bauen.

Natürlich muss man auf dem SQL Server einen User mit genügend Rechten und eventuell eine leere Datenbank für
diesen User anlegen. Soweit ich mich erinnere war das auch bei phpBB so - danach hat dieses alle Tabellen erzeugt.

Ich persönlich versuche bei SQLExpress() mit den genormten Befehlen auszukommen,
schließlich will ODBC ja unabhängig vom dem SQL Server Programm bleiben.
Allerdings gibt es schon Unterschiede (eventuell im ODBC-Treiber) die einem zum Nachdenken anregen ...
so konnte ich bei MySQL einen Append Befehl bauen, der gleichzeitig 10 oder mehr Datensätze übergeben hat.
Bei PostGreSQL ist mir das damals nicht gelungen - ist aber schon einige Jahre her !
Man kann sich leicht vorstellen, was es bedeutet 1 statt 10 Aufträge bei insgesamt 1 Million Datensätze zu benötigen.
Gerade wo Xbase++ und ODBC nicht ganz so schnell sind ;-)
Gruß
Hubert

Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Re: SQL Knowhow

Beitrag von Alfred » Mo, 21. Mär 2011 19:29

TOM hat geschrieben: Selbstverständlich kann eine Anwendung SQL-Datenbanken und -Tabellen anlegen;
Firebird-Dokumentation hat geschrieben: How to create a database from my program?
Firebird doesn't provide a way to create database using SQL.
You need to either use the Services API, or external tool.
PostgreSQL kennt ein create Database,

aber
PostgreSQL-Dokumentation hat geschrieben: Normally, the creator becomes the owner of the new database.
Superusers can create databases owned by other users, by using the OWNER clause.
They can even create databases owned by users with no special privileges.
Non-superusers with CREATEDB privilege can only create databases owned by themselves.
Gruß
Alfred

Antworten