Firebirdforum.de

Deine Ausführungen sind alle richtig. Nun stelle man sich aber ein IT-Unternehmen vor, in dem die Hälfte der Mitarbeiter "Administratoren" sind. Da mag einer Zugriff auf die Datensicherung haben, einer kümmert sich ums Netzwerk oder die Server. Da wird es schon schwierig Daten vor ungewolltem Zugriff zu schützen. Hierbei geht es nicht um Einbrüche von außen, sondern Zugriffe von innen.

Beispiel Datenschutzplattform. Dort wird eine Zweifaktorauthentifizierung eingesetzt. Der Großteil der Mitarbeiter weigert sich jedoch private Handynummern zu hinterlegen, wenn diese nicht verschlüsselt abgelegt werden. Dies wäre mit der Spaltenverschlüsselung erledigt.

Ja auch das ist korrekt. Nur der Aufwand, die Anwendung auf die Reaktion von Spaltenverschlüsselung umzustellen ist enorm.
Was ist das Ergebnis der Verschlüsselung von DateTime?
Eben, ein VarBinary. Dies führt beim Lesen ohne Entschlüsselung zum Laufzeitfehler, es sei denn, es gibt dann einen NULL-Wert.
Doch wo wird auch tatsächlich beim Select mit einer gezielten Namensnennung gearbeitet, also nur die Felder zu benennen die man braucht?
Die meisten arbeiten mit "select * ..." und beim Zugriff auf nicht erwartete NULL-Felder kommt es zu "Unzulässige Verwendung von NULL".

Wenn eine Anwendung nicht für Verschlüsselung angepasst ist, muss man die Finger davon lassen.

PCRE = Perl Compatible Regular Expressions

Ich wünsche euch allen frohe Weihnachten!

• scheduler

• aufhebung des limits von zeichen, regal ob bei bezeichnungen oder bei query's etc.

• vererbung waere toll

rene@carplus-24.de hat geschrieben: ↑Fr 2. Jun 2023, 10:45 scheduler

Ja, das würde Geraffel mit den Systemdiensten (geplante Tasks / cron) vermeiden und solche Aktionen viel besser wartbar machen

aufhebung des limits von zeichen, regal ob bei bezeichnungen oder bei query's etc.

Tatsächlich ist das mittlerweile auch der Ansatz des Ur-Architekten von Interbase/Firebird, Jim Starkey, speziell bei AmorphousDB.
https://www.odbms.org/blog/2016/08/data ... m-starkey/
https://dbdb.io/db/nuodb

vererbung waere toll

Kannst Du ein Beispiel geben, wo das sinnvoll wäre? Ich bin bisher froh, dass es wenigstens im Bereich rein relationaler DBs keine Vererbung gibt. Der Nutzen, den das Konzept Vererbung ins Spiel gebracht hat, steht mE in keinem Verhältnis zur Steigerung der Komplexität.

Und mit verschlüsselten Daten lassen sich keine Indizierungen mit komplexen Vergleichen wie Like oder auch nur > oder < durchführen.
Dafür bedarf es dann wieder unverschlüsselte Spalten.
Oder man lädt sich die Tabelle komplett in den Speicher um sie dann zu durchsuchen. Performance adee.

Meine persönliche Erfahrung:
Wenn die Daten vollkommen und ausschließlich nur durch die Anwendung erstellt und verändert werden können, reicht dies vollkommen aus.

Und wie man gerade in aktuellen Filmen so sehen kann, wird dr beim Diebstahl des Handys auch gleich der Daumen abgeschnitten. Deshalb nehme ich immer noch die sichere Pin.
Vorteil: Die Pin muss man nicht nennen, den Fingerabdruck darf man dir aber abnehmen.