Not Null bei FB3

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Antworten
Benutzeravatar
joerg_b
Beiträge: 13
Registriert: Mi 26. Sep 2018, 19:15

Di 12. Feb 2019, 18:50

ich weiss nicht , ob ich lachen oder die FB-Entwickler erschlagen sollte
seit anno 2000 arbeite ich nun mit Interbase und später dann FB . Und im laufe der Zeit es sich als Vorteil herausgestellt, numerische Domains mit NOT NULL anzulegen, das wird bei mir bei der Domain Definition definiert.

Und ich hab zig solchen Kundendatenbanken und seit Herbst letzten Jahres hab ich brav alle Tabellenaliase in den SQL Anwiesungen rausgeschmissen damit man diese auch unter FB3 einsetzten kann. Völlig sinnentleert das ganze, aber es ist eben so.
Nun muss ich ein Projekt erweitern und dazu eine mit Daten gefüllte Tabellenstruktur ändern. Unter FB 1.5 überhaupt kein Problem und schon 1000 mal gemacht.
Und unter FB3 :x eine Katastrophe.

Ein Feld verlängern indem ich die Domain ändere ... ätsch , Anlegen ja, Löschen auch, aber ändern, das geht ja gar nicht, nun ja man kann ja mit Alter Type arbeiten.
Ein Feld , das als Double Precision angelegt wurde, aber doch nur Integer enthielt, auf Integer oder gar smallint ändern ... ätsch , das mag FB3 nicht.
Und jetzt gerade dann die Krönung
Ich wollte nur ein Feld hinzufügen
Alter Table xxx add Column IS_PRIVAT DM_TRUEFALSE;
Die Domain ist vom Typ Smallint und daher mit Not Null definiert.
Beim Commit ... ätsch , geht nicht, da sind ja not null Felder.

Die kann ich aber erst nach erfolgtem Commit mit 0 oder 1 füllen.
Jetzt hab ich ne Domain ohne "Not Null" angelegt ,kann alles Ändern und updaten und dann auf die korrekte Domain zurückändern ...

Manchmal wünschte ich mir, die Entwickler müssten mit Ihrer Software auch mal selbst arbeiten
Kennt jemand eigentlich eine Möglichkeit, mit den Jungs von Firebird in Kontakt zu treten oder sitzen die (so mein Eindruck) seit Version 2.0 in einem Elfenbeinturm und wollen von der bösen Welt nicht mehr wissen. Damals gabs mal Newsgroups , aber die sind ja wohl weg.

Und klar, ich weiss, ich hab trotz des Community Sponser Beitrags keinen Anspruch auf diese oder jene Funktion. Trotzdem ist es ärgerlich, wenn man bei der tägliche Arbeit unter dem DeckMäntelchen "Sicherheit" derart behindert wird.
Schöne Grüße aus dem Südharz
Jörg
Benutzeravatar
martin.koeditz
Beiträge: 95
Registriert: Sa 31. Mär 2018, 14:35

Mi 13. Feb 2019, 12:56

Hallo Jörg,

dein Unverständnis ist teilweise nachvollziehbar. Früher konnte man Felder mittels Manipulationen in den Systemtabellen ändern. Dies ist zum Glück mit 3.0 vorbei.

Bei der Weiterentwicklung ist der eine oder andere harte Schnitt manchmal nicht vermeidbar. Die Entwickler versuchen sich am SQL-Standard zu orientieren bzw. sich diesem zu nähern. Leider sind dann einige harte Änderungen enthalten.

Zu deinem Problem:
Du kannst bei der Anlage von neuen Spalten auf Basis eines "NOT NULL"-Datentypen den Default-Wert mitgeben:

Code: Alles auswählen

Alter Table xxx add Column IS_PRIVAT DM_TRUEFALSE DEFAULT 0; 
Somit werden die Daten bereits bei der Spaltenanlage mit den korrekten Werten befüllt.

Kontakt über die devel-Mailingliste ist natürlich jederzeit möglich.


Gruß
Martin
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 81
Registriert: Mo 7. Mai 2018, 18:09

Mi 13. Feb 2019, 16:04

Die 1.5er-Version ist ja schon etwas betagter und hat eben Dinge erlaubt, die im SQL-Standard halt nicht möglich sind. Das zieht sich eben auch hin zu Domains.
Ich konnte in keiner DB (mit 1.5 habe ich nie gearbeitet) einfach den Feldtyp ändern, da dies ja ein Cast des Inhaltes erforderlich macht.
Allerdings kann man Felder hinzufügen, die Inhalte per Update kopieren und das alte Feld dann entfernen.

Aber das ist also so wie in diversen typunsicheren Sprachen. Nehme ich den Typ VAR / VARIANT, kann da von Integer über String bis Objekt alles zu jeder Zeit drinstehen.
Da finde ich persönlich typsichere Datenbanken auf jeden Fall besser und vor allem sicherer.
Benutzeravatar
joerg_b
Beiträge: 13
Registriert: Mi 26. Sep 2018, 19:15

Mi 13. Feb 2019, 22:24

danke für die Antworten, mein Blutdruck ist mittlerweile auch wieder im grünen Bereich

Aber ich mag gewisse Freiheiten, die ohne Frage auch Verantwortung mit sich bringt.
Ich programmiere halt lieber in C oder c++ als in Pascal, weil ich da einfach schreiben kann
char c = 'A' ;
c += 32 ;
und dann hab ich 'a'
find ich simpel , einfach und verständlich aber natürlich kann ich mir durch die lasche Typ-Überprüfung auch ein Lock in's Knie schiessen. Ist dann aber mein Knie. Ich kann mich erinnern, als man für sowas in Pascal noch auf Assembler zurückgreifen musste :lol:

Ich fahr auch lieber Motorrad als Auto :D

oder auf FB bezogen:
ich weiss, das ich einen String Feld in dem 'Hallo' steht, nicht in einen Double konvertieren kann. Dazu brauch ich kein FB oder kein SQL - Standard, auch keinen Uni Prof . Aber ob eine Konvertierung String nach Double vllt doch sinnvoll ist und uU auch funktioniert, das kann kein FB Entwickler oder keine SQL Standarde beurteilen, aber der jeweilige Entwickler schon.

Nur meine Meinung
Schöne Grüße aus dem Südharz
Jörg
jhoehne
Beiträge: 10
Registriert: Di 11. Dez 2018, 09:19

Do 14. Feb 2019, 09:26

Im "Firebird Book" wird empfohlen, bei der Definition von Domains das "NOT NULL" wegzulassen (damit man in der jeweiligen Tabelle die höchstmögliche Freiheit hat).
--
Joachim
bfuerchau
Beiträge: 81
Registriert: Mo 7. Mai 2018, 18:09

Do 14. Feb 2019, 18:29

Nun ja, dafür gibt es ja die bewusten CAST funktionen.
Diese gibt es in Programmiersprachen wie auch in SQL.
Da ein CHAR-Wert 'X' ebenso auch als Integer behandelt wird, hast du da keine Probleme.

SQL stellt ja nur keine Automatik zur Verfügung. Manuell hast du da die selben Freiheiten.
Antworten