Allgemeines zum Umgang mit Datenbanken

[charlytango]

so sehe ich das ja auch -- deswegen auch meine Frage wie "groß" die DB sein soll.

Natürlich hat ein ein-eindeutiger PK bei verteilten Datenbanken und Replikationen, Spiegelungen RoadWarrior-Replikationen und was es sonst noch für nette Goodies gibt unbestreitbar Vorteilen und ist bei vielem davon praktisch zwingend.

Nur muss man nicht immer mit Kanonen auf Spatzen schießen

[af0815]

Nur muss man nicht immer mit Kanonen auf Spatzen schießen

Ich wars nicht Außerdem habe ich in meinem Arsenal meistens nur Kanonen, also nehme ich die Im Datenbankbereich habe ich die Erfahrung machen müssen, das vermeintliche Spatzen in Wirklichkeit fliegende Blauwale sind. (Kunde: Ich bräuchte da noch eine kleine Änderung - und zwar nur ........)

Nein, die Frage ist ganz einfach aufgetaucht, ich nehme an ErnstVolker hat so seine Gründe dafür.

[ErnstVolker]

Guten Morgen,

jetzt habe ich wieder Netz zur Verfügung.

Der Grund für die Verwendung von Guid als PK war einerseits es ausprobieren zu wollen und andererseits die Überlegung, dass ich evtl. eine Synchronisation (mit SQLite) benötige. Es soll auch ein Tablet mit Kamera Verwendung finden, wo die in der eigentlichen Postgres-DB zu verwaltenden Objekte (Autos), mit fotografiert werden. Da das Photographieren auch im Freien erfolgt (Busse, Lkw) wo dem Tablet kein WLAN für die Verbindung zur DB zur Verfügung steht dachte ich daran einen Teil der DB auch in SQLite zu bauen und zwischen den DB's synchronisieren zu wollen. Deshalb habe ich hier auch den Beitrag zum speichern von BLOB's in SQLite verfolgt. Wobei mir das in Postgres schon gelungen ist, aber es scheint nicht sinnvoll zu sein. Besser den Link zum Bild verwenden. Hier sollte auch wieder die UUID als Dateiname für das Bild dienen. Zwar soll es auch eine Ordnerstruktur geben die nach Jahr und Monat getrennt die Bilder speichert (da könnte man dann auch im Monat April -oder Mai- des Jahres 2023 die Dateinamen "1.jpg", "2.jpg" usw. verwenden) aber zur "Sicherheit" sollte die UUID noch dienen. Zu Not hänge ich an die UUID noch "_1" usw. an.

Für jemanden der keine Ahnung hat, habe ich mir irgendwie viel vorgenommen. Ich wollte schon hinschmeißen und mir Fischertechnik Robotics besorgen um das mal zu probieren, aber dann hab' ich doch wieder eine Idee und fange an zu beißen...

Vielen Dank für Eure Hilfen und viele Grüße
Volker

[af0815]

Der Grund für die Verwendung von Guid als PK war einerseits es ausprobieren zu wollen und andererseits die Überlegung, dass ich evtl. eine Synchronisation (mit SQLite) benötige. Es soll auch ein Tablet mit Kamera Verwendung finden, wo die in der eigentlichen Postgres-DB zu verwaltenden Objekte (Autos), mit fotografiert werden. Da das Photographieren auch im Freien erfolgt (Busse, Lkw) wo dem Tablet kein WLAN für die Verbindung zur DB zur Verfügung steht dachte ich daran einen Teil der DB auch in SQLite zu bauen und zwischen den DB's synchronisieren zu wollen.

Da macht eine GUID Sinn, aber man muss es jetzt nicht zwingend als PK verwenden. Dann sieht man einfach in der Target DB nach ob der GUID schon in einem Feld gespeichert ist, wenn nicht, so überträgt man das Bild. Damit ist es auch einfacher zwischen verschiedenen DB Systemen zu replizieren. Und du hast hier den Vorteil nur in eine Richtung die Daten zu repelizieren. Damit kannst du die GUID auch als String verwenden und wenn du willst geht auch ein Hash über die GUID dann, den du beim speichern erzeugst, damit du schneller suchen/vergleichen kannst.

Zwar soll es auch eine Ordnerstruktur geben die nach Jahr und Monat getrennt die Bilder speichert (da könnte man dann auch im Monat April -oder Mai- des Jahres 2023 die Dateinamen "1.jpg", "2.jpg" usw. verwenden) aber zur "Sicherheit" sollte die UUID noch dienen. Zu Not hänge ich an die UUID noch "_1" usw. an.

Ich mache sowas laufend, da erezuge ich mir den Verzeichnamen mit "format('%.4d%.2d', [YearOf(S), WeekOf(S)]);" wobei S ein TDateTime ist.

[charlytango]

Kunde: Ich bräuchte da noch eine kleine Änderung - und zwar nur ........)

Yep -- jedesmal wenn ich so etwas hörte wie "Ich brauche ja nur..." ging ich schon in Deckung gggg. Die Deckung hat aber nie was genutzt

Der fliegende Blauwal ist eine charmante Metapher - Kompliment

[charlytango]

Der Grund für die Verwendung von Guid als PK war einerseits es ausprobieren zu wollen und andererseits die Überlegung, dass ich evtl. eine Synchronisation (mit SQLite) benötige.

In so einem Fall macht es natürlich wieder Sinn.

[Soner]

Ich habe jetzt UUID-Typ als PK untersucht und zu meiner Überraschung war die Select-Where-Abfrage ähnlich schnell wie PK als Integer bei einer Tabelle mit 727807 Datenzeilen von einer realen Datenbank.
Ich habe getestet mit Firebird 2.5. Ich verwendete als GUID-Feld den Datentyp "CHAR(36) CHARACTER SET ASCII".
Ich habe die UIDs bei Firebird mit "gen_uuid()" erstellen lassen, alles Serverseitig.

@af0815
Welche Datentyp verwendest du für UUID in Datenbanken?
Den Datentypen UUID gibt es bei Firebird 2.5 nicht.

[af0815]

@af0815
Welche Datentyp verwendest du für UUID in Datenbanken?
Den Datentypen UUID gibt es bei Firebird 2.5 nicht.

Hier ein einfaches schönes Beispiel für den MS-SQL (Mein Hauptarbeitgebiet seit Jahrzehnten)

Code: Alles auswählen

USE TestDB
GO
 
CREATE TABLE EnglishStudents1
(
	Id UNIQUEIDENTIFIER PRIMARY KEY default NEWID(),
	StudentName VARCHAR (50)
 
)
GO
 
INSERT INTO EnglishStudents1 VALUES (default,'Shane')
INSERT INTO EnglishStudents1 VALUES (default,'Jonny')

GO

Quelle: https://www.sqlshack.com/understanding- ... ql-server/
Ich finde der Artikel erklärt es recht gut, ist aber auf Englisch. Die Syntax mit dem default und dem automatischen Erzeugen wenn man nicht angibt finde ich Charmant. Allerdings kann ich genausogut meine eigene GUID beim Insert angeben, so finde ich, das das absolut Idiotensicher Also das richtige für mich.

Den MS-SQL Server kann man mittlerweile auch unter Ubuntu problemlos installieren. Da gibt es auch eine Express (und Developer) Version die man schnell verwenden kann. Ist wenn man der Anleitung folgt in ein paar Minuten installiert. Lässt sich dann über einen Windows PC mit dem SQL Server Studio von MS genauso Administrieren und Programmieren wie ein Windows SQL Server. Und die Expressversion ist für viele Anwendungen nicht wirklich eingeschränkt. Backup etc. kann man mit wenigen Scripts perfekt automatisieren. Ist für mich eine echte Alternative und lässt sich auch jederzeit hochskalieren, wenn die Anwendung größer wird.

[Socke]

Welche Datentyp verwendest du für UUID in Datenbanken?

Ich bin zwar nicht af0815, hätte aber auch etwas beizutragen.
Da ein UUID auch nur ein 128-Bit großer Binärwert ist, kann man ihn je nach Dantenbank auch als solches ablegen.
Ein CHAR(32) Feld belegt da doppelt so viel Speicher und falls die PK eine Größenbeschränkung hat, hat man mehr Platz um andere Felder im Index unterzubringen.

Die Umrechnung und Handhabung ist dann natürlich aufwändiger.

[Soner]

@socke, @af0815 Danke für die Infos.
Ich benutze die Firebird-Datenbank, dort wird für die UUID-Felder "CHAR(16) CHARACTER SET OCTETS" verwendet, aber Datenfelder mit "CHARACTER SET OCTETS" hat mit Delphi und Lazarus Probleme, bei der Ausführung von "SQL-Statements" wird sinnlose Fehlermeldungen angezeigt. Deshalb habe ich CHAR(36) Datentyp verwedendet.

Falls jemand seine eigene DB-Testen will hier ist mein Code für Firdebird. Aufpos ist die Tabelle, APNR ist normale Tabellenindex(integer/Primary key) und APNRUUID ist char(36-ASCII)-Feld zum testen. Ihr müsst es an eure DB abpassen( gen_uuid() ist wahscheinlich bei andren DB anders) und einmal "excecute procedure APNRGUID" aufrufen.

Code: Alles auswählen

CREATE PROCEDURE APNRGUID
AS
DECLARE VARIABLE ANR INTEGER;
BEGIN
  FOR SELECT APNR FROM AUFPOS INTO :ANR DO
  BEGIN
    UPDATE AUFPOS SET APNRUUID=gen_uuid() WHERE APNR=:ANR;
  END
  SUSPEND;
END;