Delphi-PRAXiS
Seite 1 von 3  1 23   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Neue Datenbank (https://www.delphipraxis.net/192248-neue-datenbank.html)

Thomas Feichtner 3. Apr 2017 08:32

Datenbank: egal • Version: egal • Zugriff über: egal

Neue Datenbank
 
Hallo,

wir suchen nach einer neuen Datenbank. Derzeit haben wir den Advantage Database Server im Einsatz. Leider ist die Zukunft dieser für mich tollen und einfachen Datenbank ungewiss.

Als wichtigen Entscheidungsfaktor ist der Kostenfaktor. Wie viel kostet die Datenbank pro Benutzer.

Hier einige Anforderungen die wir an die Datenbank stellen:

Die Datenmenge liegt hier von 1 GB aufwärts bis 100 ~ 150 GB (kann natürlich auch mehr werden). Wobei die Datenmenge nicht unbedingt einen Rückschluss auf die Anzahl der Benutzer hat.

Die Anzahl der Benutzer beträgt zwischen 1 und 100. Gerade hier bei wenigen Arbeitsplätzen ist der Kostenfaktor der Datenbank entscheidend.

Die Datenbank soll zu 99% auf einem Windowsrechner (Server) laufen.

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

Welche Datenbank würdet ihr empfehlen?
Welche Kosten kommen ca pro User für den Kunden?

Was haltet ihr von folgenden Datenbanken?
* MSSQL
* Oracle
* Postgres

mikhal 3. Apr 2017 08:54

AW: Neue Datenbank
 
Wenn du die Kosten im Auge halten willst, streiche sofort Oracle und MSSQL sowie MySQL (noch nicht auf deiner Liste).

Ich empfehle hier neben dem Open Source Produkt Postgres noch Firebird, schlank wie die Advantage Database liefert sie alles was du forderst.

Grüße
Mikhal

Bernhard Geyer 3. Apr 2017 09:55

AW: Neue Datenbank
 
Ich würde dir empfehlen gleich eine DB-Neutrale Schicht in deine Anwendung einzubauen und die gebräuchlichsten DBs (MS SQL, Oracle, MySQL) zu unterstützen.
Damit ist man nicht mehr verantwortlich das man ein DBMS-System xyz bei einem Kunden eingeführt werden muss.

jobo 3. Apr 2017 10:52

AW: Neue Datenbank
 
Neben dem Gesagten
Oracle DB ist m.E. die Mutter aller DB und verfügt über einen unglaublichen Funktionsumfang.
Alle anderen sind vereinfacht gesagt "Verfolger" in Bezug auf die Funtkionalität und Leistung.
MSSQL hat wahrscheinlich die eleganteste Anbindung für IDE, wahrscheinlich angenehm für den Entwickler, ich kenne die Details nicht persönlich.
Postgres ist von Haus aus schon immer auf den Spuren von Oracle, dies gilt für SQL (Funktionen) und SP Programmierung.
Will man 2 Systeme finden mit hoher Nähe und geringem Umstellungsaufwand, so sind es wohl Oracle und Postgres. Hier gibt es aber sicher Einschränkungen, die ich nicht alle Überblicke, bspw. Multitenancy und anderer Highend Kram.
Natürlich kann man auch wie Bernhard Geyer an die Sache gehen, eine Zwischenschicht bauen und die DB zur stumpfen Datenhaltung verwenden, sofern das in die bestehende Anwendungslanschaft / Einsatzgebiete passt. M.E. geht sowas nur/am besten, wenn die Anwendungslandschaft (alle Clients) nicht sonderlich heterogen sind.

Ich persönlich bin immer wieder von PostgreSQL begeistert, nicht nur, weil es vieles kann, was Oracle ich von Oracle gewöhnt bin, es hat auch nette Features, die man bei Oracle nicht findet, bspw im Indexingbereich.

Firebird ist spätestens seit 3 sicher auch empfehlenswert, hat sicher seine Vorteile, wenn es (auch) um embedded geht.

Wegen der Kostenfrage noch ein Hinweis:
Auch wenn PG und FB "kostenlos" zu haben sind, gibt es hier Anbieter für professionellen Support. Das sollte man sich ansehen bzw. berücksichtigen.

Phoenix 3. Apr 2017 11:29

AW: Neue Datenbank
 
Wenns billig sein muss: Gefühlt würde ich im Zweifel zu MariaDB greifen (Lizenzkostenfrei, ansonsten gleicher, zum teil größerer Funktionsumfang wie MySQL).
Postgres hatte ich jetzt schon etliche Male zwischen den Fingern, und das hat bei mir jedes mal vorne und hinten geklemmt, insbesondere Performancetechnisch.

Ansonsten bin ich ein Fan vom Microsoft SQL Server. Die Express Edition ist bis 10 GB Datenmenge auch Lizenzkostenfrei, und danach kann man entweder nach Usern/Geräten (Client Access License) oder nach Kernen des Servers (ab Enterprise Version) lizenzieren.

Ansonsten bin ich da voll bei Bernhard. Wenn Du eine gescheite Middleware reinziehst, dann bist Du von dem eigentlichen System unabhängig und kannst dann je nach Bedarf beim Kunden individuell entscheiden welche DB passt.

p80286 3. Apr 2017 11:37

AW: Neue Datenbank
 
Zitat:

Zitat von jobo (Beitrag 1366242)
Oracle DB ist m.E. die Mutter aller DB

Sie und ihre Schwestern wollen gepflegt werden, da reicht ein Feierabendadmin nicht aus.
Meine unmaßgebliche Meinung, Oracle und MSSQL tun sich in vielerlei Beziehung nichts, aber es gibt bestimmt Situationen, wo die eine oder andere ihre Vorteile hat.
Für die Datenbank zwischendurch nehme ich immer FB (und bleibe damit wahrscheinlich unter seinen Möglichkeiten).

(Wenn ich so lese wie zickig sich MySQL anstellen kann, würde ich es nicht in Betracht ziehen, aber wahrscheinlich kenn ich nur die 10 unzufriedenen, die restlichen 999999999990 sind vollauf zufrieden.)

Gruß
K-H

MichaelT 3. Apr 2017 12:18

AW: Neue Datenbank
 
Welche geht leider nicht ob der Lizenzkosten.
Mimer DB. Die tunt sich selbst. Über ODBC geht Mimer sicher. Als AnyDAC noch grad 1.x war habe ich Mimer mal probiert für OLAP Auswertungen. Fragt einmal an nach den Lizenzmodellen für VARs.

BTrieve gibt es wieder :wink:

Es gibt keine Datenbank mehr welche 'schlecht' wäre.

Aus Deutschen landen gibt es mal TurboDB.

Für mich persönlich gibt es Oracle. Oracle ist megageil, aber für echt große DBs. Ist auch ganz gut gelaufen als OEM Datenbank bei BMD (in Version 8.1.7 - noch immer).

Postgres und MariaDB
- Sind beide nicht astrein. Aber wenn du sagt, keine Business Logik in Stored Procedures. Der Rest ist schon halbwegs gegessen. Ich würde mir zuerst die Optimizing Guides und Quellen zu Optimierung anschauen.

---

MS-SQL Server ist eigen, Sybase :oops: roots.

Mich kann der SQL Server nicht ganz überzeugen. Das Pro an sich ist eine gute Doku in der alles erklärt wird bishin zur Funktionsweise der Engines usw.




Zitat:

Zitat von Thomas Feichtner (Beitrag 1366227)
Hallo,

wir suchen nach einer neuen Datenbank. Derzeit haben wir den Advantage Database Server im Einsatz. Leider ist die Zukunft dieser für mich tollen und einfachen Datenbank ungewiss.

Als wichtigen Entscheidungsfaktor ist der Kostenfaktor. Wie viel kostet die Datenbank pro Benutzer.

Hier einige Anforderungen die wir an die Datenbank stellen:

Die Datenmenge liegt hier von 1 GB aufwärts bis 100 ~ 150 GB (kann natürlich auch mehr werden). Wobei die Datenmenge nicht unbedingt einen Rückschluss auf die Anzahl der Benutzer hat.

Die Anzahl der Benutzer beträgt zwischen 1 und 100. Gerade hier bei wenigen Arbeitsplätzen ist der Kostenfaktor der Datenbank entscheidend.


Was haltet ihr von folgenden Datenbanken?
* MSSQL
* Oracle
* Postgres


Ghostwalker 3. Apr 2017 12:30

AW: Neue Datenbank
 
Man sollte, gerade bei der Anschaffung einer neuen DB-Struktur, durchaus ein Blick Richtung NoSql-Datenbanken werfen (z.B. MongoDB). Gerade hinsichtlich der Datenmenge und Geschwindigkeit sehr gut. Dazu ist das ganze Open-Source (Kostenfaktor).

Als Beispiel: GitHub setzt das ganze eine und die verwalten damit einige Terabyte an Daten. Wenn du mal auf die Hauptseite gehst und die Suche bemühst wirst du die Geschwindigkeit sehen, mit der das ganze läuft. :)

jobo 3. Apr 2017 13:08

AW: Neue Datenbank
 
ISAM und Co ist eigentlich Yesterday oder?
Ich mein, an der Problematik konkurrierender Zugriffe hat sich ja seit Jahren nichts geändert.
Warum Postgres oder mySQL oder Maria ein Problem mit SP haben sollten, ist mir nicht klar.

Zitat:

Zitat von Phoenix (Beitrag 1366246)
Wenns billig sein muss: Gefühlt würde ich im Zweifel zu MariaDB greifen

Postgres hatte ich jetzt schon etliche Male zwischen den Fingern, und das hat bei mir jedes mal vorne und hinten geklemmt, insbesondere Performancetechnisch.

Ansonsten bin ich ein Fan vom Microsoft SQL Server. Die Express Edition ist bis 10 GB Datenmenge auch Lizenzkostenfrei, und danach kann man entweder nach Usern/Geräten (Client Access License) oder nach Kernen des Servers (ab Enterprise Version) lizenzieren.

Ansonsten bin ich da voll bei Bernhard... gescheite Middleware ..

Gibt es in Maria grundlegende Unterschiede zu dem "seltsamen" Verhalten, das p80286 schon angedeutet hat?
Welche Szenarios sind den ein Performance Problem für Postgres, wenn ich fragen darf?
Die "Lizenzkosten" und sonstigen Regularien für MS SQL Server Express sind offenbar weitgehend identisch. Gibt es so auch von Oracle, ebenfalls mit den Varianten für CPU Lizensierung und per User.

Eine Mittelschicht ist nebenbei zwar elegant, aber auch ein Aufwand und Kostenfaktor.

Zitat:

Zitat von p80286 (Beitrag 1366249)
Zitat:

Zitat von jobo (Beitrag 1366242)
Oracle DB ist m.E. die Mutter aller DB

Sie und ihre Schwestern wollen gepflegt werden, da reicht ein Feierabendadmin nicht aus.
..

(Wenn ich so lese wie zickig sich MySQL anstellen kann, würde ich es nicht in Betracht ziehen

"Mutter" war durchaus historisch gemeint, aber auch funktional. XML oder JSON per SQL geht nicht in jedem anderen System nach Belieben. Pflege muss wohl überall sein, nicht unbedingt nur herstellerspezifisch, sondern eher abhängig von Volumen und Nutzungsintensität. Ein 24x7 Betrieb bspw. stellt andere Anforderungen als eine Mittelständler Buchhaltung.
Von mySQL halte ich auch nicht viel, zumal es nicht nur zickig ist, sondern mittlerweile Oracle als "Stiefmutter", um bei der Wortwahl zu bleiben. M.E. betreiben die das eher als Teaser für Ihr Kernprodukt und wollten sich etwas kostenfrei Konkurrenz (Grid) vom Hals schaffen.

mkinzler 3. Apr 2017 14:25

AW: Neue Datenbank
 
Zitat:

Von mySQL halte ich auch nicht viel, zumal es nicht nur zickig ist, sondern mittlerweile Oracle als "Stiefmutter", um bei der Wortwahl zu bleiben. M.E. betreiben die das eher als Teaser für Ihr Kernprodukt und wollten sich etwas kostenfrei Konkurrenz (Grid) vom Hals schaffen.
Wobei viel restriktiver als die Konkurrenz. Bzw. eigentlich keine Alternative für nicht OS-Produkte ( Kosten wie OracleDB).

MichaelT 3. Apr 2017 14:29

AW: Neue Datenbank
 
Ich würde mir schon auch eine Schicht dazwischen gönnen. Das hat sich auf jeden Fall bewährt.

Das Umfeld Datawarehousing ist mehr ein Fan von pur, aber ich habe in der Regel nicht mal Foreigen Key Contraints. Die werden auch in einem Dictionary verwaltet. Im Datawarehousing werden auch NULLs im logischen Primärschlüssel erlaubt und später ergänzt. Wir sagen, vor der nächsten Übertragung müssen Schlüssel da sein.

Oder es werden die Datensätze geprüft und in 2 verschiedene Partitionen geschrieben usw..

Beziehungswissen auf einer Ebene oberhalb der Tabellen ist auch im Fall von OLTP kein Schaden. Dort stellt sich wieder eher die Frage, kann 'jede' zugelassene Technologie auf die Daten schreibend und ändernd hingreifen ohne dieses informelle Beziehungswissen auszuhebeln. Aber sonst ...


Zitat:

Zitat von Phoenix (Beitrag 1366246)
Ansonsten bin ich da voll bei Bernhard. Wenn Du eine gescheite Middleware reinziehst, dann bist Du von dem eigentlichen System unabhängig und kannst dann je nach Bedarf beim Kunden individuell entscheiden welche DB passt.


jobo 3. Apr 2017 14:43

AW: Neue Datenbank
 
Zitat:

Zitat von mkinzler (Beitrag 1366273)
Zitat:

Von mySQL halte ich ..
Wobei viel restriktiver als die Konkurrenz. Bzw. eigentlich keine Alternative für nicht OS-Produkte ( Kosten wie OracleDB).

Tja, wofür soll man sich entscheiden. mySQL mit Support von Oracle oder kostenlos aus der Community?
Ich nutze es nie ernsthaft, deswegen kann ich nicht sagen, wie lebendig und kraftvoll der Community Aspekt hier noch greift. Wenn Geld ausgeben, dann nicht für Oracle mySQL oder?
Kommt man in den Cluster Bereich, sieht es vielleicht noch anders aus, da wird die Luft sowieso dünn. Hab ich aber keine Erfahrung.

Zitat:

Zitat von MichaelT (Beitrag 1366274)
Ich würde mir schon auch eine Schicht dazwischen gönnen.
..
Beziehungswissen auf einer Ebene oberhalb der Tabellen ist auch im Fall von OLTP kein Schaden. Dort stellt sich wieder eher die Frage, kann 'jede' zugelassene Technologie auf die Daten schreibend und ändernd hingreifen ohne dieses informelle Beziehungswissen auszuhebeln. Aber sonst ...

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.

p80286 3. Apr 2017 15:46

AW: Neue Datenbank
 
Nunja unter "Datawarehousing" wird ja einiges verkauft. das funktioniert auch mit inkonsistenten Datenbanken. So ähnlich wie der Autofokus bei einer Kamera, oder besser der Verwacklungsschutz, je nach dem welche Ansprüche Du hast passt es meistens gut.

(nicht das wir uns mißverstehen, ich habe da Tools gesehen, die sind Sahhhne, vor allem um Fehler zu finden!)


Gruß
K-H

himitsu 3. Apr 2017 16:07

AW: Neue Datenbank
 
Wenn man in Richtung Cross-Platform denkt, könnte man auf eine SQLite kommen, da diese bereits im Android verfügbar ist.

Was hat denn iOS ode gar OSX an Board?


Problem ist hier nur: SQLite hat nicht wirklich viele Funktionen zu bieten, aber ist dafür billig. :stupid:

mkinzler 3. Apr 2017 16:18

AW: Neue Datenbank
 
FireBird, PostGreSQL und MariaDB sind zwar nicht so billig aber auch kostenlos.

bra 3. Apr 2017 16:35

AW: Neue Datenbank
 
Wichtig ist vielleicht auch noch, wie die Performance der Server aussieht. Wir haben verschiedene Kunden mit Firebird und MSSQL-Server im Einsatz und haben die Erfahrung gemacht, dass Firebird leider sehr festplattenlastig ist. Sprich, wenn der Server langsame Festplatten hat, bricht die Performance bei Firebird massiv ein. Bei MSSQL ist das nicht so der Fall, der krallt sich dafür mehrere GB RAM.

jobo 3. Apr 2017 16:39

AW: Neue Datenbank
 
und SQLite ist zwar ziemlich billig aber nicht ziemlich schnell
(was man so hört, - ist mir noch nicht aufgefallen)
Wenig Funktionen macht wierderum nichts, wenn man sowieso eine schlaue Zwischenschicht einsetzt.

Mit einer 5D Matrix bekommt man vielleicht die wichtigsten Kriterien in den Griff. Oder der TE rückt noch mit einigen Vorgaben raus.

Bernhard Geyer 3. Apr 2017 16:56

AW: Neue Datenbank
 
Zitat:

Zitat von bra (Beitrag 1366286)
... 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?

Neutral General 3. Apr 2017 16:56

AW: Neue Datenbank
 
Zitat:

Zitat von jobo (Beitrag 1366287)
und SQLite ist zwar ziemlich billig aber nicht ziemlich schnell
(was man so hört, - ist mir noch nicht aufgefallen)
Wenig Funktionen macht wierderum nichts, wenn man sowieso eine schlaue Zwischenschicht einsetzt.

Umso mehr diese schlaue Zwischenschicht allerdings emulieren muss, desto langsamer wird das ganze nochmal.

jobo 3. Apr 2017 19:38

AW: Neue Datenbank
 
Zitat:

Zitat von Neutral General (Beitrag 1366289)
Umso mehr diese schlaue Zwischenschicht allerdings emulieren muss, desto langsamer wird das ganze nochmal.

Also ich bin kein Freund von Zwischenschichten, ich mag klassische CS Welten.
Erfahrungsgemäß bekommt die Zwischenschicht einen Loadbalancer und dann wird halt soviel Hardware gekauft/gemietet, bis der Kunde nicht mehr meckert.
Und hinten dran schnelles NoSQL.
Wie auch immer, es gibt so viele Szenarien, ich glaube nicht, dass man das seriös alles gegeneinander stellen kann.

MichaelT 4. Apr 2017 07:43

AW: Neue Datenbank
 
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:

Zitat von jobo (Beitrag 1366276)

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 4. Apr 2017 07:54

AW: Neue Datenbank
 
Zitat:

Zitat von jobo (Beitrag 1366309)
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 4. Apr 2017 09:01

AW: Neue Datenbank
 
Zitat:

Zitat von Bernhard Geyer (Beitrag 1366288)
Zitat:

Zitat von bra (Beitrag 1366286)
... 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 4. Apr 2017 09:15

AW: Neue Datenbank
 
Zitat:

Zitat von bra (Beitrag 1366340)
Zitat:

Zitat von Bernhard Geyer (Beitrag 1366288)
Zitat:

Zitat von bra (Beitrag 1366286)
... 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 4. Apr 2017 10:32

AW: Neue Datenbank
 
Zitat:

Zitat von Thomas Feichtner (Beitrag 1366344)
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 4. Apr 2017 11:05

AW: Neue Datenbank
 
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 4. Apr 2017 11:49

AW: Neue Datenbank
 
Zitat:

Zitat von mkinzler (Beitrag 1366366)
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 4. Apr 2017 11:53

AW: Neue Datenbank
 
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:

Zitat von Thomas Feichtner (Beitrag 1366344)
Und wie ist hier Prosgres?
Welche Vor oder Nachteile haben diese beiden Datenbanken(Firebird und Prostres)?


Frickler 5. Apr 2017 10:21

AW: Neue Datenbank
 
Zitat:

Zitat von Thomas Feichtner (Beitrag 1366227)
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 5. Apr 2017 22:14

AW: Neue Datenbank
 
Zitat:

Zitat von Frickler (Beitrag 1366491)
Braucht Ihr tatsächlich nur puren SQL-Zugriff, also kein ISAM

nur?

Flapsig gesagt ohne ISAM keine Datenbank.

Gruß
K-H

Thomas Feichtner 6. Apr 2017 07:06

AW: Neue Datenbank
 
Hallo Frickler,

hast du dir auch Postgres angesehen?
Zitat:

Zitat von Frickler (Beitrag 1366491)
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.

Derzeit verwenden wir schon ISAM aber davon möchten wir eigentlich wegkommen.

RSF 6. Apr 2017 08:10

AW: Neue Datenbank
 
Ich stand auch vor demselben Problem.
Jahrelang auf Grundlage ADS aufgebaut.:cry:
Ich habe mich definitiv für Postgres entschieden.:thumb:

Thomas Feichtner 6. Apr 2017 08:27

AW: Neue Datenbank
 
Hallo RFS

Zitat:

Zitat von RSF (Beitrag 1366566)
Ich stand auch vor demselben Problem.
Jahrelang auf Grundlage ADS aufgebaut.:cry:
Ich habe mich definitiv für Postgres entschieden.:thumb:

Und bereust du die Entscheidung?
Warum hast du dich nicht z.B. für FireBird oder MSSql entschieden?
Wie schwer war für die die Umstellung (Syntax,...)?

Was sagen die Kunden bzw. Edv-Betreuer zu Prosgres? Kennen sie die Datenbank oder sehen sie dich mit großen Kulleraugen an wie das leider beim ADS ein wenig war.

Benötigt man bei Postgres exclusiven Zugriff bein einer DB-Änderung?

Ich bin einfach derzeit so unentschlossen was für unser ERP-System das sinnvollste ist.

himitsu 6. Apr 2017 08:41

AW: Neue Datenbank
 
Zitat:

Zitat von Thomas Feichtner (Beitrag 1366567)
Benötigt man bei Postgres exclusiven Zugriff bein einer DB-Änderung?

Für was für Änderungen?

Für Backups mußt du lokal ran, denn pg_dump braucht Zugriff (also direkt auf dem Rechner oder über eine Netzwerkfreigabe)
sonst kann man fast alles in der DB machen. Braucht dafür nur ein Login mit genügend Rechten.

Datenbanken erstellen/löschen/kopieren geht über PGAdmin oder dein Programm.
Ein Großteil der Settings lassen sich über ein Query per SET ändern.

Thomas Feichtner 6. Apr 2017 09:01

AW: Neue Datenbank
 
Es geht zum Beispiel um Feldänderungen (Vergrößerung oder um neue Felder hinzufügen).
Ist das möglich während andere Benutzer auf die Tabelle zugreifen.
Oder einen zusätzlichen Index anlegen

Frickler 6. Apr 2017 09:32

AW: Neue Datenbank
 
Zitat:

Zitat von Thomas Feichtner (Beitrag 1366563)
Hallo Frickler,

hast du dir auch Postgres angesehen?
Zitat:

Zitat von Frickler (Beitrag 1366491)
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.

Derzeit verwenden wir schon ISAM aber davon möchten wir eigentlich wegkommen.

Ja ISAM Teile haben wir auch noch in der Software. Deswegen hatten wir uns zuerst auch NexusDB angesehen, welches als "ISAM-Datenbank mit 'angeflanschtem SQL'" einen ähnlichen Hintergrund wie ADS hat. Ist ne super Datenbank, aber die Doku ist schon etwas älter und wenn ich dann auf der Webseite lese "Version 4 just released", jetzt mit "Rad Studio XE7 support"...

Postgres habe ich mir nur kurz angeschaut, damit bin ich nicht warm geworden

In meinen Augen ein gewichtiges Argument für Firebird ist das extrem umfangreiche Datenbanktool "IBExpert". Der Ersteller dieses Tools bietet auch Expertise in Form von Schulungen, Beratung usw.

mkinzler 6. Apr 2017 09:33

AW: Neue Datenbank
 
Zitat:

Es geht zum Beispiel um Feldänderungen (Vergrößerung oder um neue Felder hinzufügen).
Ist das möglich während andere Benutzer auf die Tabelle zugreifen.
Da würde ich grundsätzlich nicht im Traum drandenken, dass Tun zu Wollen.
Zitat:

Oder einen zusätzlichen Index anlegen
Sollte kein Problem sein.

Frickler 6. Apr 2017 09:37

AW: Neue Datenbank
 
Zitat:

Zitat von Thomas Feichtner (Beitrag 1366573)
Es geht zum Beispiel um Feldänderungen (Vergrößerung oder um neue Felder hinzufügen).
Ist das möglich während andere Benutzer auf die Tabelle zugreifen.
Oder einen zusätzlichen Index anlegen

Feldänderungen während andere User auf die Tabelle zugreifen??? Benutzer A arbeitet mit Version 1.1 der Software, für die das Datenbankfeld "Blubb" ein Datumsfeld ist, währenddessen Benutzer B schon mit der neuen Version 1.2 arbeitet, die beim Update Feld "Blubb" in ein Stringfeld umwandelt... oder wie soll ich mir das vorstellen?

bernau 6. Apr 2017 09:59

AW: Neue Datenbank
 
Zitat:

Zitat von Frickler (Beitrag 1366586)
Feldänderungen während andere User auf die Tabelle zugreifen??? Benutzer A arbeitet mit Version 1.1 der Software, für die das Datenbankfeld "Blubb" ein Datumsfeld ist, währenddessen Benutzer B schon mit der neuen Version 1.2 arbeitet, die beim Update Feld "Blubb" in ein Stringfeld umwandelt... oder wie soll ich mir das vorstellen?

Es geht um Vergrößerung eines Stringfeldes oder um neues Feld anlegen. Damit trifft keiner deiner Szenarien zu.

p80286 6. Apr 2017 10:07

AW: Neue Datenbank
 
Zitat:

Zitat von mkinzler (Beitrag 1366585)
Zitat:

Es geht zum Beispiel um Feldänderungen (Vergrößerung oder um neue Felder hinzufügen).
Ist das möglich während andere Benutzer auf die Tabelle zugreifen.
Da würde ich grundsätzlich nicht im Traum drandenken, dass Tun zu Wollen.

Es gibt da einen kleinen DB-Hersteller, der das ermöglicht, (wobei die Frage ist, ob laufender Betrieb das gleiche wie auf Tabelle zugreifen ist [wahrscheinlich nicht])

Gruß
K-H


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:06 Uhr.
Seite 1 von 3  1 23   

Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf