Delphi-PRAXiS
Seite 2 von 4     12 34      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Allgemeines Datenbankproblem bei SQL Abfrage (https://www.delphipraxis.net/132183-allgemeines-datenbankproblem-bei-sql-abfrage.html)

Jens Hartmann 7. Apr 2009 19:21

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Erstmal vielen dank,

ich muss jetzt erstmal meine Hausaufgaben machen. Werde jetzt mal die Einstellungen anpassen, und nochmal die Anleitung zur Firebird lesen.

Zitat:

"Besser" ist eher eine gelinde "Besserung". Man beachte die quotes "". Das ist wie mit "Made In Germany". Erdacht als Ächtung und heute noch Qualitätssiegel. Als nicht-englisch-Muttersprachler ist es doch wirklich sehr einfach "Benutzer" zu verwenden und den ganzen unnötigen Kram aus dem Weg zu gehen.
Wie meinst Du das, ich verstehe ja, das englischen Namen besser sind, aber was meinst Du mit unnötigem Kram?


Gruß Jens

DeddyH 7. Apr 2009 19:22

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Ich hab das so verstanden, dass Du deutsche Bezeichner nehmen sollst, da diese sich mit ziemlicher Sicherheit nicht mit reservierten Bezeichnern beißen.

alex517 7. Apr 2009 19:23

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Hallo Jens,

ich habe es dir bereits hier empfohlen.

Aber nochmal:
Nur Großbuchstaben A..Z, Ziffern 0..9 und den Unterstrich für Feldnamen+Tabellen+Trigger usw. verwenden.
Keine Sonderzeichen oder Umlaute.


Desweiteren keine Standard Keywords / reserved Keywords als Feldnamen+Tabellen+Trigger verwenden.

Du machs dir das Leben damit definitv leichter!

alex

Hansa 7. Apr 2009 19:30

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Zitat:

Zitat von Jens Hartmann
...ich verstehe ja, das englischen Namen besser sind,

Ne, du hast überhaupt nichts verstanden ! Du sollst nicht den englischen allerweltsnamen "User" verwenden, sondern eher "Benutzer" oder, weil englisch gewünscht wird und die Kollision mit englisch reservierten Wörtern anscheinend gewünscht ist, notfalls zumindest "ProgramXYUser". Detaillierter : siehe Alex.

Jens Hartmann 7. Apr 2009 20:09

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Naja, aber jetzt.

ich war bis jetzt der Überzeugung, das man versuche sollte englische Bezeichner zu nehmen. Aber es klingt mir logisch. Englische Bezeichner könnten Belegt sein, und deutsche nicht. Werde jetzt nochmal die ganze Sache überarbeiten.

Hat den mal jemand in die Datenbank reingesehen, und kann mir vieleicht sagen, ob es da sonst noch irgendwelche Sachen gibt, die ich nicht verstanden habe.

Gruß Jens

PS: Danke an alle. Hat mich aufjedenfall nochmal ein bißchen näher ans verstehen der DB´s gebracht.

Jens Hartmann 8. Apr 2009 07:44

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Hallo nochmal,

ich häng mal ne simple Frage zum Thema an. Ich habe auf der IBExpert-Page folgende Anleitung gefunden.

IBExpert Doku

Da ich aber jemand bin der gerne was in Papierform hat, meine Frage, Gibt es diese Anleitung auch irgendwo als PDF oder so.

Ich weiß im Downloadbereich, aber leider nur auf Englisch. Es wäre für mich halt wesendlich einfacher in Deutsch. Vieleicht gibt es da ja irgendwas.

Gruß Jens

alex517 8. Apr 2009 08:01

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Hallo Jens,

meine Empfehlung:

- Tabelle MB100 und MB256PLUS
Feldtyp von Datum als DATE statt CHAR(10)
Feldtyp von Uhrzeit als TIME statt CHAR( 8)


- Tabelle USER umbenennen in BENUTZER
Feld Benutzer umbenennen in BENUTZER_NAME
für BENUTZER_NAME und PASSWORT statt CHAR VARCHAR verwenden

- Tabelle Config umbenennen in KONFIGURATION o.ä.
Feld ID als Primary Key hinzufügen

- SysDatum und SysTime (einmal deutsch einmal englisch!?)
als TIMESTAMP zusammenfassen.

generell:

- wie schon geschrieben, alle Tabellen, Feldname usw in GROSSBUCHSTABEN
ohne Sonderzeichen und keine reservierten oder Keywords (siehe Link).

- ALLE Tabellen sollten eine ein Feld ID als Primary Key besitzen
Diese ID hat, außer einem eindeutigen Wert, grundsätzlich keine Information.
(und ja, es kann Ausnahmen geben, aber nur in Bezug auf den Inhalt)

- Definiere die eigene Domänen.
Wenn du es nicht machst, mach es Firebird für dich automatisch und zwar
für jeder Feld eine eigene (zu sehen in den Systemtabellen).
Damit verringerst du den den Aufwand den Firebird beim Parsen der Statements hat.
Außerden hast du eine bessere Übersicht über deine verwendeten Feldtypen.

Beispiele:
SQL-Code:
  CREATE DOMAIN DOM_BENUTZER AS VARCHAR(40) COLLATE DE_DE; -- eigene Benutzerverwaltung
  CREATE DOMAIN DOM_BLOB AS BLOB SUB_TYPE 0 SEGMENT SIZE 80;
  CREATE DOMAIN DOM_BOOL AS INTEGER DEFAULT 0;
  CREATE DOMAIN DOM_CHAR10 AS CHAR(10) COLLATE DE_DE;
  CREATE DOMAIN DOM_CURRENCY AS NUMERIC(16,4);
  CREATE DOMAIN DOM_DATE AS DATE;
  CREATE DOMAIN DOM_DATETIME AS TIMESTAMP;
  CREATE DOMAIN DOM_ID AS INTEGER NOT NULL;
  CREATE DOMAIN DOM_LINK AS INTEGER NOT NULL;
  CREATE DOMAIN DOM_LINK_LOOSE AS INTEGER;
  CREATE DOMAIN DOM_INT AS INTEGER;
  CREATE DOMAIN DOM_MEMO AS BLOB SUB_TYPE 1 SEGMENT SIZE 80;
  CREATE DOMAIN DOM_NUM9_2 AS NUMERIC(9,2);
  CREATE DOMAIN DOM_PLZ AS CHAR(7) DEFAULT '';
  CREATE DOMAIN DOM_PROZENT AS NUMERIC(9,2);
  CREATE DOMAIN DOM_TIME AS TIME;
  CREATE DOMAIN DOM_VCHAR10 AS VARCHAR(10) COLLATE DE_DE;
  CREATE DOMAIN DOM_VCHAR100 AS VARCHAR(100) COLLATE DE_DE;
  ....
- Boolsche Werte als INTEGER (0/1)

- jede Tabelle bekommt Felder aus denen zu ersehen ist wann und von wem der
Datensatz angelegt und das letzte mal geändert wurde.
Das Eintragen diese Werte erfolgt über Before-Trigger die beim Insert und
Update gefeuert werden. Damit ist allein Firebird bzw. der Rechner aus dem Firebird
läuft für der Inhalt zuständig und nicht irgendein Client-Rechner oder das Programm.
Hilft ungemein beim Interpretieren der Daten, bei der Fehlersuche und
beim "Bewerten" von Kundenaussagen.


Beispiel:
DC, DM sind DOM_DATETIME,
UC, UM sind DOM_BENUTZER


SQL-Code:
CREATE OR ALTER TRIGGER TRIG_TESTTAB_BIU FOR TESTTAB
ACTIVE BEFORE INSERT OR UPDATE POSITION 1
AS
BEGIN

  IF(NEW.ID IS NULL) THEN
    NEW.ID = GEN_ID(GEN_TESTTAB_ID, 1);

  if (inserting) then
  begin
    NEW.DC = current_timestamp;
    NEW.UC = CURRENT_USER;
    /* oder wie bei uns über eine Prozedur wenn nicht mit
       unterschiedlichen Firebird-Usern gearbeitet wird
       EXECUTE PROCEDURE SP_GET_CURRENT_USER RETURNING_VALUES NEW.UC; */
  end

  if (updating) then
  begin
    NEW.DM = current_timestamp;
    NEW.UM = CURRENT_USER;
    /* EXECUTE PROCEDURE SP_GET_CURRENT_USER RETURNING_VALUES NEW.UM; */
  end
END

alex

alex517 8. Apr 2009 08:16

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:

Zitat von Jens Hartmann
Da ich aber jemand bin der gerne was in Papierform hat, meine Frage, Gibt es diese Anleitung auch irgendwo als PDF oder so.

siehe Bild im Anhang.

Zitat:

Zitat von Jens Hartmann
.. aber leider nur auf Englisch. Es wäre für mich halt wesendlich einfacher in Deutsch.

kann ich nachvollziehen, aber um Englisch wirst du als Softwareentwickler nicht drum rum kommen :wink: .

alex

Jürgen Thomas 8. Apr 2009 08:29

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Kleine Ergänzung zu Alex' Empfehlungen in #17: Inzwischen kennt Firebird den BOOLEAN-Datentyp (ich finde nicht genau, seit welcher Version). Es gibt aber immer wieder einmal ein Problem bei der Anwendung; und intern ist dieser sowieso genauso deklariert wie bei Alex' Vorschlag. Dieser "alte" Vorschlag INTEGER (0/1) (seit Interbase 4.x oder früher) hat also immer noch seine Berechtigung. Jürgen

Jens Hartmann 8. Apr 2009 08:35

Re: Allgemeines Datenbankproblem bei SQL Abfrage
 
Zitat:

siehe Bild im Anhang.
Danke Alex,
hatte ich gesehen, ist halt nur echt aufwendig die ganze Page zu drucken.

Zitat:

kann ich nachvollziehen, aber um Englisch wirst du als Softwareentwickler nicht drum rum kommen .
Ich weiß, ist halt nur nicht so einfach.
Naja, vieleicht versuch ich es mal mit der Englischen Anleitung. Das Problem ist halt bei mir auch die Zeit. Ich habe mal angefangen zu programmieren, als ich den Techniker gemacht habe, es hat mir Spaß gemacht, und ich habe angefangen eine Software für unser Unternehmen zu schreiben. Dadurch, das es halt mittlerweile eingesetzt werden soll, muss ich mich halt intensiver damit befassen. Das versuche ich halt. Und da ist natürlich Englisch für mich ziemlich Zeitintensiv.

Trotzdem, danke für deine antworten. :thumb: Werde die mal durcharbeiten. Einige Sachen habe ich gestern schon angepasst.

Zitat:

- Tabelle MB100 und MB256PLUS
Feldtyp von Datum als DATE statt CHAR(10)
Feldtyp von Uhrzeit als TIME statt CHAR(10)
Weiß nicht ob das richtig wäre, weil mir dieses als String geliefert wird, und ich diesen ja sonst umwandeln müsste. Deshalb, hatte ich zusätzlich die Felder SysDatum (SystemDatum) und SysTime (SystemZeit) eingefügt.

Gruß Jens


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:08 Uhr.
Seite 2 von 4     12 34      

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-2025 by Thomas Breitkreuz