> Ich denke, dass ANSI SQL der beste Standard ist, um solche
> wiederkehrenden Arbeiten wie das Anpassen an esoterische Formate zu
> vermeiden, auch wenn Traffic heute keine Rolle mehr spielt, ist es die
> Zeit die jedem fehlt. Nach der Anpassung der DB folgt ja oft noch die
> Pflege der betreffenden Programme.
>
> Ich empfehle die Festlegung auf ANSI SQL 92, weil der Standard von
> allen hier verwendeten DBs 'verstanden' wird- ANSI SQL99 includiert den
> 92er.
>
> Hier eine Übersicht
> http://www.little-idiot.de/linuxsolutionguide/datenbanken.htm
>
> Allerdings gibt es für das Eingangs genannte Problem "'Level' ist
> geschütztes Wort in Oracle und darf kein Feldname sein" o.ä. auch im
> ANSI m.E. keine Entsprechung. Es ist schlicht ein Fehler des Parsers
> der Oracle-Engine an jener Stelle auf seine Funktionen zu beharren und
> nicht einen Namen zu vermuten, wie andere DBs. Oracle ist für mich
"level" ist lt. SQL92 oder SQL93 ein reserviertes Wort. Insofern verhält
sich Oracle schon richtig, wenn auch wenig flexibel.
Es soll aber eine gültige Methode sein, Feldbezeichner in Doppelhäkchen
zu setzen, um damit reservierte Wörter zu erlauben. Vielleicht ändere
ich das Exportprogramm mal dahingehend.
> lange her: oft genügte die Syntax Tabellenname.Feldname statt nur
> 'Feldname' um Abhilfe zu schaffen (und ist vielleicht auch korrekt).
> Dies nur am Rande.
>
> Standards dienen zur Feststellung der Abweichung. ;-)
;-)
> Es kann also sein, dass trotz einer sauberen Standardisierung 'einige'
> nicht um das Adaptieren rumkommen. Besser als 'fast alle'.
>
Das wird wohl so sein. Eigentlich trenne ich mich ungern vom 'text'
Datentyp in Postgres, der zum einem deutlich effektiver als z.B.
varchar(500) sein soll, zum anderen aber auch keine Längenbeschränkung
besitzt.
Weiter weiß ich nicht, ob ein Datentyp 'boolean' bereits im SQL92
existierte. Eigentlich finde ich ihn "schön". Natürlich könnte man
wieder auf '0' und '1' zurückgehen, klar.
Es wäre natürlich praktisch, wenn wir nur noch eine 0.2er Version
zu exportieren hätten (== SQL92). Und dann könnte man ein paar
Skripte zur Verfügung stellen, die diese Daten für verschiedene
andere Systeme konvertieren oder optimieren.
Ich denke mal darüber nach.
Thomas
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
|
