Neue Datenbank

[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)?