Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Vergleichende Doku HSQL Postgres gesucht
14 views
Skip to first unread message
Marc Santhoff
Jun 16, 2012, 12:55:05 PM6/16/12
to
Tag,
ich suche schon länger nach einem Dokument, das die sytaktischen
Unterschiede in der DDL zwischen HSQL und PostrgeSQL gegenüberstellt.
Konverter für Datenbanken und Dokumente darüber gibt es, aber zu meinem
Problem konnte ich bis jetzt nichts finden. Wenn's nix gibt muß ich halt
das Rad neu erfinden, aber lieber wäre mir was fertiges, wenn auch
unvollständig ...
Konkret geht es darum einen SQL-dump von HSQL nqach PostgreSQL zu
überführen.
Kennt jemand eine solche Aufstellung? Wo?
Marc
ich suche schon länger nach einem Dokument, das die sytaktischen
Unterschiede in der DDL zwischen HSQL und PostrgeSQL gegenüberstellt.
Konverter für Datenbanken und Dokumente darüber gibt es, aber zu meinem
Problem konnte ich bis jetzt nichts finden. Wenn's nix gibt muß ich halt
das Rad neu erfinden, aber lieber wäre mir was fertiges, wenn auch
unvollständig ...
Konkret geht es darum einen SQL-dump von HSQL nqach PostgreSQL zu
überführen.
Kennt jemand eine solche Aufstellung? Wo?
Marc
Siegfried Schmidt
Jun 16, 2012, 2:46:57 PM6/16/12
to
Marc Santhoff schrieb:
> ich suche schon lÀnger nach einem Dokument, das die sytaktischen
> Unterschiede in der DDL zwischen HSQL und PostrgeSQL gegenÃŒberstellt.
HSQL:
"Very extensive support for SQL:2008 Standard syntax, including most
optional features"
Psql:
"PostgreSQL prides itself in standards compliance. Its SQL implementation
strongly conforms to the ANSI-SQL:2008 standard."
Also eigentlich sollte ein derartiges Dokument gar nicht nötig sein. ;)
Siegfried
> ich suche schon lÀnger nach einem Dokument, das die sytaktischen
> Unterschiede in der DDL zwischen HSQL und PostrgeSQL gegenÃŒberstellt.
HSQL:
"Very extensive support for SQL:2008 Standard syntax, including most
optional features"
Psql:
"PostgreSQL prides itself in standards compliance. Its SQL implementation
strongly conforms to the ANSI-SQL:2008 standard."
Also eigentlich sollte ein derartiges Dokument gar nicht nötig sein. ;)
Siegfried
Marc Santhoff
Jun 16, 2012, 3:37:39 PM6/16/12
to
OK, dann versuche ich als nächstes einfach mal den Dump nach PSQL
reinzuleiern ...
Danke für den Hinweis,
Marc
Siegfried Schmidt
Jun 16, 2012, 3:54:34 PM6/16/12
to
Marc Santhoff schrieb:
> OK, dann versuche ich als nÀchstes einfach mal den Dump nach PSQL
> reinzuleiern ...
Na dann berichte auch mal über das Ergebnis. Es ist immer gut zu erfahren,
was Standards in der Praxis wert sind.
Siegfried
> OK, dann versuche ich als nÀchstes einfach mal den Dump nach PSQL
> reinzuleiern ...
Na dann berichte auch mal über das Ergebnis. Es ist immer gut zu erfahren,
was Standards in der Praxis wert sind.
Siegfried
Marc Santhoff
Jun 16, 2012, 5:36:26 PM6/16/12
to
Der ganze Block zu Anfang des HSQL-dumps ist nicht nutzbar, sind zum gut
Teil technische Parameter für HSQL.
Die CREATE TABLE-Syntax ist nicht gleich. HSQL kennt das Schlüselwort
CAHED, kein Äquivalent in Postgres. Die Syntax für automatisch generierte
Primärschlüsselwerte ist unterschiedlich.
Mehr später, ich wollte nicht den ganzen Abend dran sitzen ...
Fazit bis hierher:
Es geht nicht so einfach. Neben der Unterstützung von Standards gibt es
(wie erwartet) deutliche Unterschiede in der Auslegung und auch in den
über den Standard hinaus gehenden proprietären Möglichkeiten der DBen.
Mal gucken, ob ich so weiternache, es handelt sich um einen einmaligen
Fall.
Marc
Marc Santhoff
Jun 16, 2012, 5:37:59 PM6/16/12
to
Am Sat, 16 Jun 2012 21:36:26 +0000 schrieb Marc Santhoff:
> Die CREATE TABLE-Syntax ist nicht gleich. HSQL kennt das Schlüselwort
^s
> Die CREATE TABLE-Syntax ist nicht gleich. HSQL kennt das Schlüselwort
> CAHED, kein Äquivalent in Postgres. Die Syntax für automatisch
Marc
Dieter Nöth
Jun 16, 2012, 6:17:35 PM6/16/12
to
Marc Santhoff wrote:
> Die CREATE TABLE-Syntax ist nicht gleich. HSQL kennt das Schlüselwort
> CAHED, kein Äquivalent in Postgres.
Das ist auch kein Wunder, Standard SQL kümmert sich nur um die logischen
> Die CREATE TABLE-Syntax ist nicht gleich. HSQL kennt das Schlüselwort
> CAHED, kein Äquivalent in Postgres.
Zusammenhänge, da gibt's keinen "Index", das kann/muss jeder Hersteller
machen, wie er will.
> Die Syntax für automatisch generierte Primärschlüsselwerte ist
> unterschiedlich.
könnte man sich leicht dran halten.
> Fazit bis hierher:
> Es geht nicht so einfach. Neben der Unterstützung von Standards gibt es
> (wie erwartet) deutliche Unterschiede in der Auslegung und auch in den
> über den Standard hinaus gehenden proprietären Möglichkeiten der DBen.
portieren, da wäre sonst die Kundenbindung viel schwieriger :-)
Zum Trost, die Übereinstimmungen beim SELECT sind um einiges höher :-)
Dieter
Siegfried Schmidt
Jun 17, 2012, 8:00:07 AM6/17/12
to
Marc Santhoff schrieb:
> Der ganze Block zu Anfang des HSQL-dumps ist nicht nutzbar, sind zum
> gut Teil technische Parameter fÃŒr HSQL.
Kann man den Dump nicht per Parameter näher an den Standard zwingen? Bei
Postgres gibts dafür z.B. xpg_dump.
Eine andere Möglichkeit wäre noch ein Datenbankdesigner, der den
Import/Export von beiden Seiten unterstützt.
> Fazit bis hierher:
> Es geht nicht so einfach. Neben der UnterstÃŒtzung von Standards gibt
> der DBen.
Wäre ja auch zu schön gewesen.
Siegfried
> Der ganze Block zu Anfang des HSQL-dumps ist nicht nutzbar, sind zum
Kann man den Dump nicht per Parameter näher an den Standard zwingen? Bei
Postgres gibts dafür z.B. xpg_dump.
Eine andere Möglichkeit wäre noch ein Datenbankdesigner, der den
Import/Export von beiden Seiten unterstützt.
> Fazit bis hierher:
> Es geht nicht so einfach. Neben der UnterstÃŒtzung von Standards gibt
> es (wie erwartet) deutliche Unterschiede in der Auslegung und auch in
> den Ìber den Standard hinaus gehenden proprietÀren Möglichkeiten
> der DBen.
Wäre ja auch zu schön gewesen.
Siegfried
Marc Santhoff
Jun 17, 2012, 12:50:22 PM6/17/12
to
Am Sun, 17 Jun 2012 12:00:07 +0000 schrieb Siegfried Schmidt:
> Marc Santhoff schrieb:
>
>> Der ganze Block zu Anfang des HSQL-dumps ist nicht nutzbar, sind zum
>> gut Teil technische Parameter fÃŒr HSQL.
>
> Kann man den Dump nicht per Parameter näher an den Standard zwingen? Bei
> Postgres gibts dafür z.B. xpg_dump.
Guter vorschlag und interessanter Hinweis, xpg_dump kannte ich noch nicht.
> Marc Santhoff schrieb:
>
>> Der ganze Block zu Anfang des HSQL-dumps ist nicht nutzbar, sind zum
>> gut Teil technische Parameter fÃŒr HSQL.
>
> Kann man den Dump nicht per Parameter näher an den Standard zwingen? Bei
> Postgres gibts dafür z.B. xpg_dump.
Ist aber hier nicht anwendbar, ich habe nur den Dump und sonst nix. Das
sind meine Daten, aber das Programm rückt nichts anderes raus.
> Eine andere Möglichkeit wäre noch ein Datenbankdesigner, der den
> Import/Export von beiden Seiten unterstützt.
>> Fazit bis hierher:
>> Es geht nicht so einfach. Neben der UnterstÃŒtzung von Standards gibt
>> es (wie erwartet) deutliche Unterschiede in der Auslegung und auch in
>> den Ìber den Standard hinaus gehenden proprietÀren Möglichkeiten der
>> DBen.
>
> Wäre ja auch zu schön gewesen.
Open Source DBen sich etwas kooperativer aufführen. Wozu die ganzen
Standards, wenn sich ncihtmal die daran halten ... :P
Marc
Siegfried Schmidt
Jun 17, 2012, 1:20:00 PM6/17/12
to
Marc Santhoff schrieb:
> Wenn Du einen Namen hÀttest? Ich bin nur Gelegenheitsnutzer und -DBA.
Schau mal da rein - vielleicht hilft dir etwas davon weiter.
http://stackoverflow.com/questions/2691068/creating-an-er-diagram-for-
hsqldb-that-exports-sql
Über Tauglichkeit kann ich nichts sagen, ich verwende hauptsächlich den
DeZign, aber der kann nicht mit HSQL umgehen.
Siegfried
> Wenn Du einen Namen hÀttest? Ich bin nur Gelegenheitsnutzer und -DBA.
Schau mal da rein - vielleicht hilft dir etwas davon weiter.
http://stackoverflow.com/questions/2691068/creating-an-er-diagram-for-
hsqldb-that-exports-sql
Über Tauglichkeit kann ich nichts sagen, ich verwende hauptsächlich den
DeZign, aber der kann nicht mit HSQL umgehen.
Siegfried
Marc Santhoff
Jun 17, 2012, 1:24:38 PM6/17/12
to
Am Sat, 16 Jun 2012 16:55:05 +0000 schrieb Marc Santhoff:
> ich suche schon länger nach einem Dokument, das die sytaktischen
> Unterschiede in der DDL zwischen HSQL und PostrgeSQL gegenüberstellt.
Nichmal konkret zu dem Problem, und zwar zu automatisch vergebenen
> ich suche schon länger nach einem Dokument, das die sytaktischen
> Unterschiede in der DDL zwischen HSQL und PostrgeSQL gegenüberstellt.
Primärschlüsselwerten.
HSQL 'dump'ed:
CREATE TABLE PUBLIC.BIBLIO(N_ID INTEGER GENERATED BY DEFAULT AS IDENTITY
(START WITH 21) NOT NULL PRIMARY KEY,
Bei Postgres habe ich bis jetzt enfach die Abkürzung benutzt:
CREATE TABLE "Event" ( "ID" serial NOT NULL PRIMARY KEY,
Ein Dump von Postgres sieht so aus:
CREATE TABLE addresses (
id integer NOT NULL,
ALTER TABLE ONLY addresses
ADD CONSTRAINT addresses_pkey PRIMARY KEY (id);
Wie kann ich hier den Startwert setzen? In der Doku habe ich bis jetzt
nichts gefunden.
Marc
Siegfried Schmidt
Jun 17, 2012, 1:35:11 PM6/17/12
to
Marc Santhoff schrieb:
> Ein Dump von Postgres sieht so aus:
>
> CREATE TABLE addresses (
> id integer NOT NULL,
>
> ALTER TABLE ONLY addresses
> ADD CONSTRAINT addresses_pkey PRIMARY KEY (id);
Da fehlt die zugehörige Sequenz.
> Wie kann ich hier den Startwert setzen? In der Doku habe ich bis jetzt
> nichts gefunden.
Ein "CREATE TABLE event (id serial)" erzeugt implizit die Sequenz
"event_id_seq". Den Startwert von Sequenzen kannst du mit setval()
ändern. Siehe Dok unter "Sequenzen".
Siegfried
> Ein Dump von Postgres sieht so aus:
>
> CREATE TABLE addresses (
> id integer NOT NULL,
>
> ALTER TABLE ONLY addresses
> ADD CONSTRAINT addresses_pkey PRIMARY KEY (id);
> Wie kann ich hier den Startwert setzen? In der Doku habe ich bis jetzt
> nichts gefunden.
"event_id_seq". Den Startwert von Sequenzen kannst du mit setval()
ändern. Siehe Dok unter "Sequenzen".
Siegfried
Marc Santhoff
Jun 17, 2012, 1:46:45 PM6/17/12
to
Am Sun, 17 Jun 2012 17:35:11 +0000 schrieb Siegfried Schmidt:
> Marc Santhoff schrieb:
>
>> Ein Dump von Postgres sieht so aus:
>>
>> CREATE TABLE addresses (
>> id integer NOT NULL,
>>
>> ALTER TABLE ONLY addresses
>> ADD CONSTRAINT addresses_pkey PRIMARY KEY (id);
>
> Da fehlt die zugehörige Sequenz.
Ja, hab' ich in dem recht umfangreichen Dump übersehen ...
> Marc Santhoff schrieb:
>
>> Ein Dump von Postgres sieht so aus:
>>
>> CREATE TABLE addresses (
>> id integer NOT NULL,
>>
>> ALTER TABLE ONLY addresses
>> ADD CONSTRAINT addresses_pkey PRIMARY KEY (id);
>
> Da fehlt die zugehörige Sequenz.
>> Wie kann ich hier den Startwert setzen? In der Doku habe ich bis jetzt
>> nichts gefunden.
>
> Ein "CREATE TABLE event (id serial)" erzeugt implizit die Sequenz
> "event_id_seq". Den Startwert von Sequenzen kannst du mit setval()
> ändern. Siehe Dok unter "Sequenzen".
Danke!
Marc
Marc Santhoff
Jun 17, 2012, 4:40:04 PM6/17/12
to
Und noch mehr, so aufwendig hatte ich es trotz allem nicht erwartet:
Weiß jemand, wie ich dem cleint psql beibringe, alle Eingabe nicht
automatisch in Kleinbuchstaben umzuwandeln?
Allein die man page ist so umfangreich, daß man das halbe Spiel
verpaßt ...
HSQL gibt alle in GROSSSCHREIBUNG aus. ich möchte jetzt nicht alle
Tabellen- und Feldnamen von Hand in Anführungszeichen setzen müssen.
Marc
Weiß jemand, wie ich dem cleint psql beibringe, alle Eingabe nicht
automatisch in Kleinbuchstaben umzuwandeln?
Allein die man page ist so umfangreich, daß man das halbe Spiel
verpaßt ...
HSQL gibt alle in GROSSSCHREIBUNG aus. ich möchte jetzt nicht alle
Tabellen- und Feldnamen von Hand in Anführungszeichen setzen müssen.
Marc
Peter Schneider
Jun 17, 2012, 6:27:39 PM6/17/12
to
Hallo,
Bei einer DB, die entfernt ANSI-SQL compliant ist, sind Identifier
(Feld-/Tabellennamen) case-insensitiv.
Nur wenn Du quoted Identifier verwendest sind sie case sensitiv. Wenn psql den
Input umwandelt, sollte das also wurst sein.
Gruß
Peter
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
(Feld-/Tabellennamen) case-insensitiv.
Nur wenn Du quoted Identifier verwendest sind sie case sensitiv. Wenn psql den
Input umwandelt, sollte das also wurst sein.
Gruß
Peter
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
Marc Santhoff
Jun 17, 2012, 6:40:33 PM6/17/12
to
Statements nur noch INSERT INTO VALUES(...) mit vollständiger Werteliste
ohne Namen folgen. Es geht hier nur um die Konsistenz der Daten.
Noch eine Spezialität von HSQL: der typ VARCHAR_IGNORECASE, nicht in
Postgres bekannt. Kann man sicher nachbilden, aber auch nicht nötig.
Marc
Marc Santhoff
Jun 17, 2012, 6:43:19 PM6/17/12
to
Am Mon, 18 Jun 2012 00:27:39 +0200 schrieb Peter Schneider:
> Am 17.06.2012 22:40, schrieb Marc Santhoff:
>> HSQL gibt alle in GROSSSCHREIBUNG aus. ich möchte jetzt nicht alle
>> Tabellen- und Feldnamen von Hand in Anführungszeichen setzen müssen.
>
> Bei einer DB, die entfernt ANSI-SQL compliant ist, sind Identifier
> (Feld-/Tabellennamen) case-insensitiv.
>
> Nur wenn Du quoted Identifier verwendest sind sie case sensitiv. Wenn
> psql den Input umwandelt, sollte das also wurst sein.
Sollte, ist aber nicht der Fall. Wenn ich die großgeschriebenen
> Am 17.06.2012 22:40, schrieb Marc Santhoff:
>> HSQL gibt alle in GROSSSCHREIBUNG aus. ich möchte jetzt nicht alle
>> Tabellen- und Feldnamen von Hand in Anführungszeichen setzen müssen.
>
> Bei einer DB, die entfernt ANSI-SQL compliant ist, sind Identifier
> (Feld-/Tabellennamen) case-insensitiv.
>
> Nur wenn Du quoted Identifier verwendest sind sie case sensitiv. Wenn
> psql den Input umwandelt, sollte das also wurst sein.
Tabellennamen nicht in "" einbette, wird bei der automatischen Definition
der Sequence für den Serial-Typen die Tabelle nicht gefunden. Mit ""
klappt's dann.
Womöglich gibt es dafür einen Schalter auf der Server-Seite (SET
irgendwas).
Aber siehe anderes Posting ...
Marc
Marc Santhoff
Jun 17, 2012, 6:52:38 PM6/17/12
to
Am Sun, 17 Jun 2012 22:40:33 +0000 schrieb Marc Santhoff:
> Strategiewechsel, die Namen lasse ich so, da danach im Dump als
> relevante Statements nur noch INSERT INTO VALUES(...) mit vollständiger
> Werteliste ohne Namen folgen. Es geht hier nur um die Konsistenz der
> Daten.
>
> Noch eine Spezialität von HSQL: der typ VARCHAR_IGNORECASE, nicht in
> Postgres bekannt. Kann man sicher nachbilden, aber auch nicht nötig.
Jetzt geht's vorwärts.
> Strategiewechsel, die Namen lasse ich so, da danach im Dump als
> relevante Statements nur noch INSERT INTO VALUES(...) mit vollständiger
> Werteliste ohne Namen folgen. Es geht hier nur um die Konsistenz der
> Daten.
>
> Noch eine Spezialität von HSQL: der typ VARCHAR_IGNORECASE, nicht in
> Postgres bekannt. Kann man sicher nachbilden, aber auch nicht nötig.
Noch eine HSQL-igkeit: in den Dumps ist kein Semikolon am Ende der Zeile.
Mit sich langsam entkräuselnder Stirn grüßt
Marc
Siegfried Schmidt
Jun 18, 2012, 7:24:56 AM6/18/12
to
Marc Santhoff schrieb:
> Noch eine SpezialitÀt von HSQL: der typ VARCHAR_IGNORECASE, nicht in
> Postgres bekannt. Kann man sicher nachbilden, aber auch nicht nötig.
Es gibt keine derartige eingebaute Spalteneigenschaft in Postgres.
Einen caseinsensitiven Stringtyp und alle dazu nötigen Operatoren und
Funktionen findest du in pgsql/contrib/citext.
Siegfried
> Noch eine SpezialitÀt von HSQL: der typ VARCHAR_IGNORECASE, nicht in
> Postgres bekannt. Kann man sicher nachbilden, aber auch nicht nötig.
Es gibt keine derartige eingebaute Spalteneigenschaft in Postgres.
Einen caseinsensitiven Stringtyp und alle dazu nötigen Operatoren und
Funktionen findest du in pgsql/contrib/citext.
Siegfried
Marc Santhoff
Jun 18, 2012, 11:37:32 AM6/18/12
to
abfedern.
Mit pgsql verlasse ich dann gleich schon wieder den Pfad der DB-
Unabhängigket ...
Egal, nach ein paar Reibereien mit "Escae Strings", nämlich daß alle
Zeichenketten, die den Backslash (Rückwärtsschrägstrich?) enthalten, für
Postgres Escape Strings sein müssen, also "E'...'".
Wobei ich alle Vorkommen vorher durch "\\" ersetzen durfte, um Posgres
mitzuteilen, daß eben gerade nicht interpretiert werden soll (wtf? in
String nix escapen durch escape strings mit escaptem escape-Zeichen?),
bin ich fertig mit der Angelegenheit. Puh.
Vielen Dank allen Helfern!
Marc
Andreas Scherbaum
Jun 19, 2012, 3:15:47 PM6/19/12
to
PostgreSQL versteht das sowohl klein- wie auch groß geschrieben. Nur
wenn du das mit Anführungszeichen versiehst wird das in jedem Fall so
gesucht wie du das angibst.
Aufpassen, Stolperfalle:
CREATE TABLE "Gross" (...);
SELECT ... FROM Gross
Funktioniert dann nicht mehr, du musst dann auch im SELECT die "" verwenden.
Den Spaß findet man gern wenn irgendwo Frameworks im Spiel sind, die
pauschal alles quoten.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
Message has been deleted
Marc Santhoff
Jun 22, 2012, 7:19:37 PM6/22/12
to
Am Wed, 20 Jun 2012 17:41:19 +0000 schrieb Stefan Ram:
> Marc Santhoff <M.San...@t-online.de> writes:
>>Backslash (Rückwärtsschrägstrich?)
>
> »inverser Schrägstrich« nach DIN 66003.
:)
> http://www.purl.org/stefan_ram/pub/dv_schriftzeichen_de
Danke,
Marc
> Marc Santhoff <M.San...@t-online.de> writes:
>>Backslash (Rückwärtsschrägstrich?)
>
> »inverser Schrägstrich« nach DIN 66003.
:)
> http://www.purl.org/stefan_ram/pub/dv_schriftzeichen_de
Danke,
Marc
Marc Santhoff
Jun 22, 2012, 7:24:38 PM6/22/12
to
Am Tue, 19 Jun 2012 21:15:47 +0200 schrieb Andreas Scherbaum:
> Marc Santhoff <M.San...@t-online.de> wrote:
>>
>> Und noch mehr, so aufwendig hatte ich es trotz allem nicht erwartet:
>>
>> Weiß jemand, wie ich dem cleint psql beibringe, alle Eingabe nicht
>> automatisch in Kleinbuchstaben umzuwandeln?
>>
>> Allein die man page ist so umfangreich, daß man das halbe Spiel verpaßt
>> ...
>>
>> HSQL gibt alle in GROSSSCHREIBUNG aus. ich möchte jetzt nicht alle
>> Tabellen- und Feldnamen von Hand in Anführungszeichen setzen müssen.
>
> Solange du keine "" um die Bezeichner setzt, ist das alles egal.
> PostgreSQL versteht das sowohl klein- wie auch groß geschrieben. Nur
> wenn du das mit Anführungszeichen versiehst wird das in jedem Fall so
> gesucht wie du das angibst.
Klar, ist bekannt. Ich war nur nicht sicher, ob in dem umfangreichen Dump
> Marc Santhoff <M.San...@t-online.de> wrote:
>>
>> Und noch mehr, so aufwendig hatte ich es trotz allem nicht erwartet:
>>
>> Weiß jemand, wie ich dem cleint psql beibringe, alle Eingabe nicht
>> automatisch in Kleinbuchstaben umzuwandeln?
>>
>> Allein die man page ist so umfangreich, daß man das halbe Spiel verpaßt
>> ...
>>
>> HSQL gibt alle in GROSSSCHREIBUNG aus. ich möchte jetzt nicht alle
>> Tabellen- und Feldnamen von Hand in Anführungszeichen setzen müssen.
>
> Solange du keine "" um die Bezeichner setzt, ist das alles egal.
> PostgreSQL versteht das sowohl klein- wie auch groß geschrieben. Nur
> wenn du das mit Anführungszeichen versiehst wird das in jedem Fall so
> gesucht wie du das angibst.
noch irgendwo Überraschungen versteckt sind. War aber nicht, nur INSERT
mit vollem Spaltensatz ohne Spaltenname.
> Aufpassen, Stolperfalle:
>
>
> CREATE TABLE "Gross" (...);
>
> SELECT ... FROM Gross
>
>
> Funktioniert dann nicht mehr, du musst dann auch im SELECT die ""
> verwenden. Den Spaß findet man gern wenn irgendwo Frameworks im Spiel
> sind, die pauschal alles quoten.
Unklarheiten im semantischen Datenzusammenhang dann der Client ausbügeln
muß. Da der aber wohl neu erstellt wird, ist das nur Fleißarbeit.
Auch, daß da jeder sein Ssystem für die Tabellennamen hat. Würde mich
nicht wundern, wenn's auch dazu eine DIN EN ... gibt.
Marc
0 new messages