Neue Datenbank

[MichaelT]

Die Kritik ist mehr als berechtigt.

Ich halte von Applikationsdatenpersistenz in einer DB und nur zu diesem Zwecke schlicht gar nichts. Klar ist ein abgesichertes Informationsmodell besser und Normalisierung schadet schon gar nicht.

Sobald du aber Nachrichten empfängst und Cleansing betreibst schaut die Welt anders aus und beim Staging sowieso. Auch wenn Datawarehouses oder so an Datamart angelehnte Architekturen langsam verschwinden ziehen sich diese Bausteine eher wieder ins operative Umfeld rein. Sobald du Analyse in eine Anwendung(ssystem) einbaust wirst du nicht umhinkommen eine Art Datenkrake zu gebären.

Für mich ist eine Anwendung auch nichts anders als eine Weg auf ein Informationsmodell zuzugreifen. Das wäre eher die Oracle Philosophie.

Zitat von jobo:

Weiß nicht, ob ich das richtig verstanden habe. Aber wenn ich eine DB kastriere und sie als dummen Datencontainer nutze, muss halt die Zwischenschicht das auffangen. Wenn sie es nicht kann, habe ich ein Problem oder ich lasse es halt drauf ankommen. Eigenes Risiko.

[Bernhard Geyer]

Zitat von jobo:

Also ich bin kein Freund von Zwischenschichten, ich mag klassische CS Welten.

Wer sagt den das eine solche Zwischenschicht sich auch in einer physikalisch/Logisch getrennten Anwendung niederschlagen muss.
Wir haben auch ein DB-Neutrale Zwischenschicht eingebaut und haben trotzdem nur eine Exe.

Macht man wirklich dann auch noch ein N-Tier-Lösung daraus, so muss man aufpassen das die Verteilung auf viel unterschiedliche (virtuelle) Rechner das nicht erstmal sehr viel langsamer macht.
Ich glaube aber nicht das das im vorliegenden Fall nötig sein wird.

[bra]

Zitat von Bernhard Geyer:

Zitat von bra:

... Bei MSSQL ist das nicht so der Fall, der krallt sich dafür mehrere GB RAM.

Und? Wenn man bei einer 150 GB Datenbank z.B. 30 GB RAM für den Server vorsieht. ist das in 2017 noch ein nennenswerter Kostenfaktor wenn dafür das DB-System gegenüber 8 GB RAM 100fache Leistung bietet da alle relevanten Indexe komplett im RAM vorgehalten werden könnne?

Ich sehe das ja auch genauso, Firebird ist in der Hinsicht halt deutlich im Nachteil, weil der bei einer langsamen Festplatte in die Knie geht, weil er fast nichts cacht.

[Thomas Feichtner]

Zitat von bra:

Zitat von Bernhard Geyer:

Zitat von bra:

... Bei MSSQL ist das nicht so der Fall, der krallt sich dafür mehrere GB RAM.

Und? Wenn man bei einer 150 GB Datenbank z.B. 30 GB RAM für den Server vorsieht. ist das in 2017 noch ein nennenswerter Kostenfaktor wenn dafür das DB-System gegenüber 8 GB RAM 100fache Leistung bietet da alle relevanten Indexe komplett im RAM vorgehalten werden könnne?

Ich sehe das ja auch genauso, Firebird ist in der Hinsicht halt deutlich im Nachteil, weil der bei einer langsamen Festplatte in die Knie geht, weil er fast nichts cacht.

Und wie ist hier Prosgres?
Welche Vor oder Nachteile haben diese beiden Datenbanken(Firebird und Prostres)?

[jobo]

Zitat von Thomas Feichtner:

Und wie ist hier Prosgres?
Welche Vor oder Nachteile haben diese beiden Datenbanken(Firebird und Prostres)?

Ich habe keine individuellen Vergleichszahlen, vermutlich ist PG schneller. Wenn nicht out-of-the-box, dann letztlich mittels sehr fortschrittlicher Indexierung.
Postgres hat auf jedenfall einen riesigen Schatz an Funktionen/SP, ist dort sehr mächtig.

RAM und Harddisk
Jede Datenbank wird schneller, wenn sie genug RAM (Buffer) hat und schnelle Platten, wenn also Hauptspeicher zum Puffern von Daten, Index genutzt wird und Sortier, Gruppier Läufe in memory laufen können.
Wie das in % vergleichsweise unter den beiden aussieht kann ich nicht sagen. Vlt gibt's da Rankings im Netz.

Ansonsten:
Wenn Du etwas zum Einsatzgebiet sagen würdest, könnte man die vielen Wenns und Abers etwas präzisieren.

[mkinzler]

Etwas älter, stimmt Vieles nicht mehr:

https://www.heise.de/ct/artikel/Frei...5.html?seite=2

http://db-engines.com/de/system/Fire...L%3BPostgreSQL

[jobo]

Zitat von mkinzler:

Etwas älter, stimmt Vieles nicht mehr:

Ja, an vielen Stellen kam mir Stirnrunzeln.

Hier noch 2 Beiträge zu PG ohne Bezug zu FB, da kannst du vielleicht selber abschätzen, ob was spannendes für Dich dabei ist und bei Bedarf direkt selbst nachschlagen, wie es aktuell in FB aussieht.

https://www.compose.com/articles/wha...sql-databases/
https://www.compose.com/articles/wha...bases-part-ii/
(auch diese Aufzählungen beinhalten gehen gemäß Datum nicht die letzten Features von PG, das ist vielleicht Stand 9.4 oder max 9.5)

[MichaelT]

Postres ist eine andere Architektur, weswegen vor und und Nachteile schwer zu benennen sind.

Ich habe schon mit AnyDAC massive Array Updates reingeschoben in einen Firebird genauso.

Sagen wir es mal anders.
Es gibt einen Unterschied zwischen ODBC und OLEDB der solange nicht auffällt bis du 1 Mio. Sätze pro Paket musst in einen SQL Server jagen, bspw. für ein Planungs- und Analysesystem basierend auf Analysis Services.

Postgres ist eine Liga drüber. Postgres wäre vergleichbar mit einer Oracle OEM oder VAR in etwa mit Bezug auf deinen Anwendungsfall. Ich kenne Anwendungen die bis 500 User schaffen in der alles inkl. Reporting auf einer DB machen.

---
Postgres kann mit einer Oracle nicht mithalten im oberen Segment. Oracle hat ein eigenes Filesystem bspw. unter UNIX ... Du kannst die Stored Procedures (Diana Intermediate Language) auf dem gcc durchcompilieren bis zur ganzen DB Verwaltung usw... Oracle *brauchst* du wenn zu die Daten nicht mehr migrieren kannst. Oracle hat ein mehrschichtige Architektur mit sovielen Layern, dass der Sau graust. Wenn du bspw. nicht weißt ob dein Programm morgen nicht in einer Org. mit 3000 User läuft usw...

Mir war mal fad, dann hab ich mir vor langer Zeit einen Dataset gebastelt der die Änderungen aus exportierten DB Blöcken hat gelesen, wobei Dataset ein wenig übertrieben wäre.
---

Der SQL Server war bis SQL Server 2005 resp. 2008 (Feature eingeschalten) immer fleißig beim Setzen von Sperren insbesondere Readlocks.

Klarerweise kannst du mittlerweile den SQL Server Speicherverbrauch begrenzen.

---

Der große Unterschied der DBs ist bei Änderungen im Livebetrieb. Neu ist aber eher die Anforderungen DB Mechanismen einfach zu begrenzen. SQL Server und Oracle sind eher Monolithen. Egal in welche Skalierung diese Datenbanken sind immer proportional überpowered für den konkerteten Anwendungsfall.

Lizenzierung. Eine Oracle Seat Lizenz hängt nicht an der Anzahl der Server auf die du zugreifst . Je nachdem wie verhandelt wird.

MySQL und NexusDB wären eher die ersten modularen Zugänge. Der SQL Server hat zwar auch unterschiedliche Storage Engines, aber so wie bei einer MySQL kannst du diese nicht tunen. Wenn du sagst ich will für meine Anwendung einen besseren Recordserver dann kannst du alles andere wegschalten.

Wenn du noch einen Cluster Fahren willst usw... Das Thema DB aus Sicht der Applikationspersistenz ist seit 2k erledigt. In gewisser Weise ist es schade um SQL Anywhere bspw. die so in die Nähe von Advantage kommt. Der Ersatz wäre Postgres oder NexusDB usw... Im Gegensatz zu den großen Monolithen ist die Verwaltung einfach. Mimer wäre auch noch die Liga, die ist pflegeleicht im Enterprise Umfeld.

Bei den Monolithen SQL Server und Oracle (aus Sicht des Endkunden sicher noch immer monolithisch) erbst du eine gewisse Komplexität mit in jedem Fall. Das hat 2 Seiten.

a) Der kleine Kunde der gewohnt war die DB zu überpowern wird von der Power erschlagen, wie alle anderen gieriegen 'Beidln' welche die DB schwarz kopiert haben vor 20 Jahren und fest Stored Procedures geschrieben haben. Stored Procedures schützen das Businessmodell des Herstellers wie ein File Format ein DOS Textverarbeitung.
b) Je nach Anwendung gegen die Oracle DB Analysewerkzeug für das DB Schema und den PL/SQL Code laufen (ClearDB Documentor und ClearSQL bspw.). Die Dokumentation ist dann am Server und für andere Entwickler zugänglich usw... (Kann man alles mit Hausmitteln auch machen, ... aber soviel Menschen sitzen nicht in IT Abteilungen und haben viel Zeit).

NexusDB habe ich vor einem Weilchen auch noch gemacht. Die wäre schon ein Beispiel für exzessiv modular. Bei der brauchst du einzig und allein das DB File 'anders' ansprechen in dem du andere Komponenten in der Application aktivierst oder du kommuniziert Rechner lokal usw... Verschlüsselung je nach belieben. Damit bist du schon eher auf der sicheren Seiten, da du bspw. höhere Security bei der Übertragung (wie es vor einer Zeit war) nicht musst extra Zahlen pro Arbeitsplatz. Bei MS hast du das Problem immer auf lange Sicht.

Der Betrieve war der letzte klassische Recordserver. Datensatzart in einem File (wie einer DB2). DBASE oder XBASE war ähnlich. Diese DBs holen die ersten paar 100k Sätze so enorm schnell. Dadurch, dass sie Record mit Strings fixer länge wunderbar lässt in ein Objekt ummappen kommt ORM freihaus. Der Varchar ist intern auch immer mit fester Länge versehen zumeist in 3 Kategorien. Die SQL DBs sind Blockserver resp. Pageserver.

Wir haben eine zeitlang ein paar (in Österreich gibt es deren nicht so viele) Clipper Applikationen müssen ablösen. Die DB Frage war immer heikel wegen dem spezifischen DB Protokoll. RDS oder wie das hieß ...

Zitat von Thomas Feichtner:

Und wie ist hier Prosgres?
Welche Vor oder Nachteile haben diese beiden Datenbanken(Firebird und Prostres)?

[Frickler]

Zitat von Thomas Feichtner:

Was soll die SQL-Datenbank alles können?
* Normale Abfragen (SELECT mit Subselect,...)
* Volltextsuche
* Stored Procedure
* Functions
* Trigger
* Transaktionen
* Bei einigen Kunden ist auch eine Replikation notwendig

Braucht Ihr tatsächlich nur puren SQL-Zugriff, also kein ISAM (Locate(), Filter(), SetRange(), explizites Locking via TAdsTable)? Dann ginge jede SQL-Datenbank. Zu MSSQL gibts Berge an Büchern und Doku, außerdem ist die Express Version bis 10 GB kostenlos, nutzt dabei aber maximal 1 GB RAM. Da die Performance von MSSQL - wie andere bereits schrieben - stark vom nutzbarem Speicher abhängt, könnte das stärker limitieren als die nutzbare Datenbankgröße.

Wir stehen von dem gleichen Problem und werden wahrscheinlich auf Firebird umsteigen. Die Fähigkeiten reichen uns und die Installation und Wartung ist um Klassen einfacher als bei MSSQL.

[p80286]

Zitat von Frickler:

Braucht Ihr tatsächlich nur puren SQL-Zugriff, also kein ISAM

nur?

Flapsig gesagt ohne ISAM keine Datenbank.

Gruß
K-H