|
"" bei SQL bzw. Interbase
Hallo Leute !
weiß jemand vielleicht, was die "" bei CREATE TABLE zu bedeuten haben? Habe 2 tables angelegt. KG für Kundengruppe und kunde für Kunden. Wenn ich sage er solle KG anlegen kommt : CREATE TABLE KG bei kunde kommt aber: CREATE TABLE "kunde" Bei der table kunde kriege ich später Ärger bei den Triggern. Er sagt mir : Generator nicht definiert, obwohl er da ist. Die Indexstruktur bei kunde ist wesentlich komplizierter als bei KG. Ist da vielleicht noch ein Fehler drin ??? Finde nirgendwo eine Erklärung über die Bedeutung der "". Gruß Hansa |
Hallo Hansa,
zeige hier bitte die ganze SQL-Scripts für die Tabelle KUNDE bzw. für GENERATOR und TRIGGER Gruß Paul Jr. |
Hallo Hansa,
die Syntax
Code:
ist nicht korrekt. Der Name der Tabelle darf nicht in Anführungsstriche eingefasst werden. Je nach verwendeter Datenbank ist es aber trotzdem denkbar, dass man damit "durchkommt" (siehe unten). IB sollte hier einen Fehler melden.
CREATE TABLE "kunde"
Bei LocalSQL sind die Anführungsstriche erlaubt, da du dort im Namen dann auch Sonderzeichen wie z.B den Punkt verwenden kannst und damit die Endung des Dateinamens z.B. DB oder DBF erlaubt wird. Die BDE erkennt dann, dass der Name der Tabelle nur der Teil vor dem Punkt ist und der Teil danach nur den Typen (Paradox, dBase) angibt. Sie sind aber nicht notwendig. Standardmäßig wird eine Paradox Tabelle angelegt. |
Hallo MrSpock,
die Aussage: Zitat:
IB 6.0.2 (meines Wissens nach alle 6.x) arbeiten grundsätzlich CaseINsensitive, d.h. Groß-Kleinschreibung kann gemischt werden. Wenn man allerdings Tabellennamen,Triggers,... in " setzt arbeitet man Casesensitive und zusätzlich kann man alles mögliche als Tabellennamen benutzen. Allerdings würde ich dieses nicht benutzen, da man sonst wie Hansa sehr schnell gegen eine Wand läuft. Vermutlich hast Du (Hansa) beim Trigger den kunde nicht in Anführungszeichen gesetzt... Grüße Lemmy P.S.: Hi Hansa, ich bin wieder da... :witch: |
Hei Leute,
das ist ja schon mal gut, wenn sich überhaupt jemand meldet. Mit PaulJr habe ich fast schon nicht mehr gerechnet :mrgreen: . Aber das hier muß ich mir erst mal heute abend angucken. Mein Netzwerk ist hinüber und nähert sich erst langsam wieder dem Leben. Wenn ich den erwische, der das war.:dance: (<-- so sieht der dann aus!!). War gottseidank selbst nicht da. Vor 10 Min. habe ich wenigstens Internet in Gang gesetzt. Das ist der erste Test. Vorab SQL - Script :
Code:
Wo ich das hier sehe fällt mir auf, daß die Felder auch in "" stehen. Der Typ IDtyp ist von mir als Domain angelegt worden. Der steht auch in "". :nerd: Den Hauptschlüssel habe ich auf die ID von kunde8 gesetzt.
/* Table: kunde8 */
SET SQL DIALECT 3; SET NAMES ISO8859_1; /******************************************************************************/ /* Tables */ /******************************************************************************/ CREATE TABLE "kunde8" ( ID "IDtyp" NOT NULL, ID_KGH "IDtyp" NOT NULL, ID_KGU "IDtyp" NOT NULL, "nr" "IDtyp" NOT NULL, "Anrede" STR25, "name" STR25 NOT NULL, "strasse" STR25, "Ort" STR25 ); /******************************************************************************/ /* Primary Keys */ /******************************************************************************/ ALTER TABLE "kunde8" ADD CONSTRAINT "PK_kunde8" PRIMARY KEY (ID); /******************************************************************************/ /* Foreign Keys */ /******************************************************************************/ ALTER TABLE "kunde8" ADD CONSTRAINT "FK_kunde8" FOREIGN KEY (ID_KGH) REFERENCES KG8 (ID); /******************************************************************************/ /* Privileges */ /******************************************************************************/ Der DS enthält auch noch einen Foreign-Key der aus der Kundengruppen-Datei stammt. Mit den Foreign-Keys habe ich auch noch Ärger. Irgendwas stimmt da noch nicht. Gruß Hansa @Admin: Bei mir ist BBcode standardmäßig deaktiviert, muß es also von Hand einschalten, das war vorher anders. ?????? :D |
Moin Hansa,
und was steht in Deinem Profil unter BBCode immer aktivieren? |
Hi Hansa,
machst Du die DB neu oder werkelst Du an einer rum die schon existiert?? Wenn es sich um ne neue DB handelt, dann mach sie neu. Du mischt ja CaseInsensitive und Casesensitive, das wird Dir das Kreuz brechen, weil Du irgendwann nicht merh durchblickst.... Grüße Lemmy |
Zitat:
|
@Admin : Bei mir gibts kein "BBcode immer aktivieren"
Hallo Lemmy, Zitat:
Vielleicht liegt es aber auch an meiner IBconsole (i.e. IBexpert) aus Flensburg. Zumindest Teile der Scripte wurden hiervon automatisch erzeugt. Nimmt er die Feldnamen, so wie sie von Hand eingegeben wurden, und baut diese in einen Trigger ein, ja dann gibt es vielleicht Ärger. Werde deshalb die DB neu aufbauen und auf Groß/Kleinschreibung achten. Plausibel wäre es schon, daß die " bedeuten, auf CaseSensitive umzuschalten. Aber dann kommt das von IBexpert und nicht von mir. :cat: Mit einem Trigger habe ich nämlich auch Ärger. Er beschwert sich ein Generator sei nicht da, obwohl er da ist (liegt vielleicht auch an CaseSensitive). @PaulJr : restliche Scripte :
Code:
Hier sieht man schön (alles Original), daß bei dem Generator alles groß und beim Trigger alles kleingeschrieben ist. Demnach würde eventuell CaseSensitive zuschlagen, warum auch immer. Holger Klemt (IBexpert) hat mir noch keine Antwort hierauf gegeben. Die Vermutung (Casesensitive / -insensitive) hatte ich nämlich auch. :mrgreen:
CREATE GENERATOR GEN_KG8_ID;
SET GENERATOR GEN_KG8_ID TO 70 CREATE TRIGGER KG8_BI0 FOR KG8 ACTIVE BEFORE INSERT POSITION 0 AS begin new.ID = GEN_ID (gen_kg8_id,1); end Gruß Hansa |
Allo ich hab in meinem Profile ein: "BBCode immer aktivieren:"
|
Hi Hansa,
Zitat:
Grüße Lemmy |
Hallo Lemmy,
also es liegt meiner Ansicht nach wirklich an IBexpert. Vielleicht ist es in der IBconsole aber genauso. Habe jetzt die Generator- und Triggernamen alle groß geschrieben. Um dies zu tun, mußte ich die Tabelle kunde8 aber leider löschen, zumindest auf die Schnelle ging es nicht anders. Der Fehler in dem einen Trigger (Fehlermeldung : GEN_kunde8_ID exist. nicht) ist jetzt auch weg. Der Generator heißt jetzt GEN_KUNDE8_ID, sonst ist nichts verändert. Meine ursprüngliche Frage, was es mit den " auf sich hat, ist also fast geklärt. Zitat:
Gruß Hansa |
Hi,
mir ist gerade noch eingefallen, in Delphi muß man dann aber auch aufpassen mit FieldByName usw. Dieser ganze Mist ist Unix zu verdanken. :twisted: Gruß Hansa |
Oh je,
Zitat:
Dann habe ich noch einen Generator, den ich droppen wollte : IBE$VERSION_HISTORY_ID_GEN Dieser wurde von mir beim Ausprobieren irgendwann einmal erzeugt. Was er macht weiß ich nicht genau. Er lässt sich aber nicht mehr löschen. Irgendwas wie "not defined for system tables". Fazit : Lemmy hat Recht ! Man kann sich leicht das Genick brechen. :mrgreen: Vor allem dann, wenn man es so macht, wie es richtig wäre, aber doch nicht so ist. Gruß Hansa :freak: |
Hallo Hansa, 8)
mit Domänen habe ich bis jetzt nicht so viel experimentiert, da ich solche Konstrukte (wg. Kompatibilität mit anderen SQL Datenbanken) maide. Nun bin ich aber neugierig geworden :mrgreen: ... und frage Dich... wie sieht die SQL- Definition von der besagten Domäne... da die Benutzung von selbst definierten Domänen sollte zumindest mit irgendwelchem logischem Bedarf begründet werden... es sei dem Du experimentierst gerade... Wie auch immer... meine SQL-Scripts halte ich immer in Großbuchstaben, da NICHT nur InterBase (wie ich hier sehe) hat manchmal damit Probleme. Vor ein paar Monaten musste ich alle Query-Scripts einer Anwendung, die auch unter ORACLE lief , auf Großschreibung umzustellen..., da manche Oracle-Versionen es nicht gepackt haben.... Aus diesem Grund empfiehlt sich auch für Dich sämtliche Scripts in Großbuchstaben zu halten. Bin mir nicht sicher, aber vielleicht Deine selbstdefinierte Domäne lässt sich deswegen nicht umbenennen bzw. löschen da diese in Deinen Tabellen für Feld-Definitionen verwendet wird. Gruß Paul Jr. |
Hallo PaulJr,
Code:
Um in einem größeren Programm Fehler zu vermeiden, legt man sich ja selber Typen an. Brauche z.B. öfters string [25]. Deshalb die Domain STR25.
CREATE DOMAIN "IDtyp" AS
INTEGER NOT NULL CREATE DOMAIN STR25 AS CHAR(25) CHARACTER SET ISO8859_1 COLLATE ISO8859_1 In Interbase kommt noch hinzu (siehe oben), daß nicht nur die Länge des strings, sondern auch noch die Sortierreihenfolge, der Character Set ,NOT NULL usw. in der Domain hinterlegt ist. Hätte ich keine Domain, müßte ich bei jedem String [25] das alles von Hand machen, inklusive Fehlersuche. Sollten die Felder für irgend jemand länger werden müssen, so kann ich dann mit ALTER DOMAIN dies entsprechend anpassen, nur kürzer werden dürfen sie nicht. Hinzu kommt noch, daß Interbase ohne Domain für jedes Feld, also auch für die ID automatisch eine Domain anlegt. Und zwar für JEDE ID. Was Speicherplatz braucht und nichts bringt. Dafür die Domain IDtyp. Gruß Hansa :witch: |
Hi,
Habe jetzt die DB gelöscht und lege sie neu an. Alles in GROßBUCHSTABEN. Sieht besser aus als vorher. Dafür fehlt mir jetzt der BEFORE UPDATE Trigger. Hat jemand ein Beispiel ? Wie sage ich immer : Datensicherung nicht vergessen !! :oops: Gruß Hansa |
Hallo Hansa, 8)
(...) Um in einem größeren Programm Fehler zu vermeiden, legt man sich ja selber Typen an. Brauche z.B. öfters string [25]. Deshalb die Domain STR25. (...) Zwar weiß ich nicht welche Programm Fehler Du in diesem Zusammenhang meinst... sind jedoch Deine weitere Ausführungen (aus Sicht Deiner Bedürfnisse) zu diesem Thema OK. Vielleicht sollte man an dieser Stelle einen Begriff erwähnen der hier am besten passen würde: Domänenintegrität dessen Einsatzbereich reicht viel, viel weiter....als der hier vorgetragenen... und oft sind diese was der Einsatz betrifft mit Trigger vergleichbar bzw. Austauschbar...! Nun warum habe ich Dir eigentlich diese Frage gestellt? Da ich hier folgendes gesehen habe:
Code:
was gewiss nur ein Versehen sein dürfte, da:
ID "IDtyp" NOT NULL,
Code:
schon reichen müsste…
ID IDTYP,
Sonnst... weiter so... :D Gruß Paul Jr.
Code:
CREATE TRIGGER ANSCHRIFT_UPDATE FOR ANSCHRIFT BEFORE UPDATE POSITION 0 AS
BEGIN NEW.AENDDATUM='NOW'; IF (NEW.KURZNAME='') THEN NEW.KURZNAME=NULL; END^ |
Zitat:
noch was zum Thema Domains von mir: Interbase hat die unangenehme Eigenschaft für jeden verwendeten Datentyp (z.B in einer Tabelle(Attribute), StoredProcedure (Übergabeparameter)), eine automatisch erzeugte Domain anzulegen, außer das Attribut wurde mit einer DOmain erzeugt. Das hat 2 Nachteile: 1. die bekommen automatisch erzeuge Namen, die nix aussagen, 2. Selbst bei einer kleinen Datenbank bekommst Du sehr schnell sehr viele Domains zusammen. Das macht ein Backup/Restore Sau langsam und die Datenbank wird unnötig aufgebläht. Leider kann man bei StoredProcs noch keine Domains benutzen... :-( Grüße Lemmy |
Hallo Lemmy, 8)
natürlich sind solche Argumente (wie die Deine) zu beachten... So oder so... der Einsatz von Domänen dürfte schon etwas mehr sein als NUR Platz... bzw.... Geschwindigkeit Gewinn bei RESTERE/BECKUP....Funktionen...da... sollte man (laut diesem Prinzip) bei 100 Tabellen einer Anwendung NUR Domänen (Selbstdefinierten Datentypen) verwendet...wäre dann das Perfekte SQL-Spript-Chaos entstanden... Bis heute habe ich das (zum Glück) noch nirgendwo erlebt... Ich weiß aber schon wie Du das meinst (gewiss als einer von vielen Argumenten dafür...)... nun es gibt’s auch welche die dagegen sprechen dürften...usw... Na ja... ein ID Feld als Domäne sehe ich Wahrhaftig zum ersten mall... ist aber nicht weiter schlimm... so lange man noch zu Hause programmiert... :mrgreen: Gruß Paul Jr. |
Hallo PaulJr,
Zitat:
Die "" kamen ja sowieso nicht von mir !! Bleibt immer noch die Frage, ob es nur mit IBexpert so ist. Wenn ich Zeit habe, probiere ich es mal mit der IBconsole. Zu dem IDtyp : Habe halt mit Domains experimentiert und somit gleich auch der ID eine Domain verpaßt. Jetzt sagst du, so etwas noch nicht gesehen zu haben. Nun interessiert mich natürlich, was da dahinter steckt. Wenn es keiner so macht, heißt das ja noch lange nicht, daß es verkehrt ist (vielleicht gibts die Domains ja noch gar nicht so lange). Du benutzt sie nicht, bei Lemmy kommts mir so vor, daß er froh damit ist. Jedenfalls verwendet er sie. Dafür sie NICHT zu benutzen sehe ich kein Argument. Was soll denn da in den Scripten durcheinander geraten ? Am Anfang ist es vielleicht etwas mehr Arbeit. Wenn dadurch die Systemtabellen übersichtlicher bleiben, dürfte es sich aber schnell auszahlen. Gruß Hansa |
Hallo Hansa, 8)
zugegeben meine Formulierung: (...) „ist aber nicht weiter schlimm... so lange man noch zu Hause programmiert...“ (...) ist etwas unglücklich (ungerecht) gewählt und schießt etwas übers Ziel hinaus... verzeih... :oops: ______________________________________ Das ändert allerdings nichts an der Tatsache, dass Domänen ein etwas umstrittener Konstrukt sein dürften... zumindest wenn man sich dann NUR mit Domänen umgibt... Bei dieser Gelegenheit erwähnt man oft als Argument die bessere Performance die man dadurch erreichen kann... nun...die Frage ist... ab wie vielen Tabellen bzw. ab welcher SQL- Projekt-Größe lohnt sich das überhaupt. Ab und zu kann man solche bzw. ähnlichen Diskussionen beobachten... die als Einziges Thema z.B. die Schnelligkeit bestimmten Konstrukte gegenüber anderen Konstrukte haben. Ich glaube sogar gestern hier in Forum irgendwas über beenden von Prozeduren bzw. Funktionen, wahlweise durch EXIT oder durch kontrollierte EXCEPTION, gelesen zu haben. Es wurde gesagt das die Exception etwas langsamer sind...usw... und das sollte als Argument dienen (!?). Vor Jahren diskutierte man z.B. auch oft über die IF...THEN...ELSE Anweisung...gegenüber der CASE Anweisung (wenn ich mich nicht irre)....usw... Was ist eigentlich schnell bzw. langsam in der Computer-Welt von Nanosekunden? Was hat also dann Priorität? Die bessere Lesbarkeit und Übersichtlichkeit... oder 2 Nanosekunden an Verlusten? Das Gleiche gilt auch für angebliche bzw. wirkliche Platz-Ersparnisse etc... Ich lasse diese Fragen offen... Jeder muss wissen was für ihn das beste ist... allerdings sollte man etwas kritischer diese Sachen unter die Lupe nehmen und nicht alles was in den Bücher steht muss unbedingt als 10-Gebote gelten...oder? Ich weiß noch nicht welche Argumente hier... für bzw. gegen Verwendung von Domänen in größeren Datenbank-Projekten noch kommen...(wenn’s überhaupt) darum enthalte ich mich noch mit genaueren Analisen, da ich zur Zeit noch kein Bedarf sehe... Ich sehe oft Entwicklung eines DB-Projekts z.B. aus der Sicht seines Umfangs, Wartbarkeit, Einsatzgebietes usw... Was noch einmal die Domänen betrifft, habe ich hier meiner Meinung nach (was mich etwas stört) noch kein einziges Wort über das wichtigste Einsatz-Gebiet von denen gehört...nämlich gar nichts über den CHECK- Einsatz bzw. Default Werte usw... Ein beliebtes Beispiel zu diesem Thema dürfte das Postleitzahlen-Problem agieren... Tja... vielleicht findest Du Hansa selbst etwas was auch gegen Domänen sprechen dürfte...aber auch wenn nicht... würde ich mich an Deiner Stelle auch NICHT durch meine Meinung beeinflussen lassen... :!: , da wie ich meine Domänen kann man verwenden...muss man aber nicht... Gruß Paul Jr. |
Hi PaulJr,
Zitat:
Das sind Diskussionen, die geführt wurden, als große Firmen noch Disketten als Massenspeicher nutzten. Im Zusammenhang mit einer DB sind folgende Aspekte viel wichtiger : sind die Indices richtig definiert? Ist das nicht der Fall, kannst du die ganze DB vergessen. Dann könnte man noch etwas darauf achten, die Records und PageSize aufeinander abzustimmen, um unnötige Ladevorgänge (vielleicht wegen einem Byte) zu vermeiden. Die Nanosekunden - Spezialisten würden dann wahrscheinlich die maximale Page-Size wählen, um sicher zu gehen, daß er nur einmal auf die Platte zugreift :mrgreen: Daß je nach Betriebssystem, Datenmenge oder Filesystem Unterschiede bestehen... :mrgreen: Zitat:
Zitat:
Meiner Meinung nach sieht der goldene Mittelweg so aus : 1. Achte auf deine Indices 2. Kümmere dich nicht zu sehr um die System-Domains, die du sowieso nicht verstehst 3. Benutze Domains, falls du viele Felder gleichen Typs und auch sonst gleicher Eigenschaften brauchst. 4. Bevor du jemand dein Programm gibst, mache ein Backup/Restore und guck dir die Größen und die Zeiten an. 5. experimentiere auch mit großen Datenmengen und eventuell der PageSize. Diese 5 Gebote (ohne Gewähr) stelle ich mal so in den Raum. Wahrscheinlich ist es aber so, wie bei den 10 Geboten : Irgend jemand hält sich sowieso nicht dran. :mrgreen: Gruß Hansa |
Hi,
hier kam ja auch das Thema Domains zur Sprache. Also ich habe im Moment keine eigene Domain. Habe mich anderweitig :mrgreen: auch mal umgesehen, da kam z.B. die Nachricht, daß die Kompatibilität z.B. bei Oracle eine andere sei. Man sollte auch das Programmieren im Team nicht aus den Augen verlieren. :shock: Jetzt hatte ich mal ein paar Domains angelegt und damit experimentiert. Nach einer Woche Unterbrechung fing ich wieder an. Da merkte ich, daß ich mir zuerst einmal angucken mußte, welche Domains ich hatte und manchmal schrieb ich dann doch CHAR (20) obwohl es eine Domain string20 gab. Außerdem habe ich mal hochgerechnet, daß ich vorrausichtlich bis zu 50 Tables brauche. Das war zwar kein Team, aber ich mußte mich doch wieder in mein eigenes Programm eindenken. Wenn ich jemand anderem das Script der DB geben würde, würde der wahrscheinlich fluchen. Außerdem : Sag niemals nie. Vielleicht kriege ich ja doch irgendwann etwas mit Oracle zu tun. :dancer2: Was übrig bleibt, sind nur die Bool-Felder. In einem Fall hatte ich einen alten Datenbestand in IB konvertiert. Da stand plötzlich in einem CHAR (1) Feld, wo nur 1 oder 0 rein darf ein K drin und die DB stürzte ab. Da überlege ich noch, eine Domain anzulegen mit CHECK, VALUE usw. Für das bei jedem Feld von Hand zu machen wäre zu viel Arbeit. Hat da einer Erfahrung mit :?: Das Kompatibilitäts-Problem wird übrigens in Zukunft noch größer. Borland hat letzte Woche Interbase 7 angekündigt, mit BOOL-Feldern und die DB endet mit .IB statt .GDB. (englischer) Bericht :  http://www.dbginc.com/tech_pprs/ib7/IB7.htm Wenn ich das mal brauche, was ist denn dann mit meinen Bool-Domains ? :duck: Gruß Hansa |
Hallo Hansa, 8)
(...) „...Das war zwar kein Team, aber ich mußte mich doch wieder in mein eigenes Programm eindenken. Wenn ich jemand anderem das Script der DB geben würde, würde der wahrscheinlich fluchen...“ (...) Manchmal muss man Schmerzhaft seine eigene Erfahrungen machen... und für sich selbst das richtige Weg zu finden... aber wie man so sagt...: „Besser später als NIE!“... Nun mit Deiner Aussage stehen plötzlich meine frühere Ausführungen zu diesem Thema im etwas anderem Licht...das freut mich... ... bin jetzt echt gespannt was meinen dazu die Befürworter...(muss aber nicht sein... da Deine Äußerung reicht hier vollkommen...) Gruß Paul Jr. |
Hi,
als Beführworter :mrgreen: melde ich mich doch noch zu Wort: Grundsätzlich gilt: Man sollte sich immer im Klaren sein, was man macht. Bei einer AdressenDB für den privaten Gebrauch wird der Einsatz von Domains sicherlich nicht unbedingt notwendig sein. Aber damit ist es IMHO wie mit der Verwendung/Bezeichnung von Variablen beim Programmieren. Ich habe am Anfang auch keine Domains verwendet, weil mir der Sinn und die vielseitige Verwendbarkeit (Checks,...) noch nicht klar war. Inzwischen habe ich in meiner DB (60 Tabellen mit um die 600 Attributen, 100 SP) an der ich seit 2 Jahren arbeite, 23 Domains verwendet und musste nur sehr selten (ein oder zweimal) eine weitere Domain erzeugen, weil die bisherigen nicht ausreichten. Klar war dafür eine gewisse Planung notwendig, aber die macht man (zumindest ich) nach einigen schlechten Erfahrungen automatisch. Wenn man nach einiger Zeit mit seinen eigenen Definitionen nicht mehr klar kommt, macht den typischen Fehler: schlechte Dokumentation (mach ich auch immer wieder). In einem Team gilt das gleiche: entweder gut dokumentieren oder eine Vereinbarung treffen, wie z.B. Domains aussehen sollen und zu welchem Zweck die angelegt werden und zuguter letzt wieder die Dokumentation. Ich will hier niemanden überreden Domains bei IB zu verwenden. Ich habe gute Erfahrungen damit gemacht, nur die kann ich teilen.... :dancer: Grüße Lemmy |
Hi,
da ich diesen Thread angefangen habe, der Vollständigkeit halber noch folgendes : http://www.entwickler-forum.de/webx?...j7S.0@.ee8da46Bitte einmal durchlesen ! Es geht um Domains und Stored Procedures. Ich finde das da ist nicht so ganz ohne. Gruß Hansa |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 11:23 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz