|
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:
|
AW: Neue Datenbank
Zitat:
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. |
AW: Neue Datenbank
Zitat:
|
AW: Neue Datenbank
Zitat:
Welche Vor oder Nachteile haben diese beiden Datenbanken(Firebird und Prostres)? |
AW: Neue Datenbank
Zitat:
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. |
AW: Neue Datenbank
Etwas älter, stimmt Vieles nicht mehr:
 https://www.heise.de/ct/artikel/Frei...5.html?seite=2http://db-engines.com/de/system/Fire...L%3BPostgreSQL |
AW: Neue Datenbank
Zitat:
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) |
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:
|
AW: Neue Datenbank
Zitat:
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. |
AW: Neue Datenbank
Zitat:
nur?Flapsig gesagt ohne ISAM keine Datenbank. Gruß K-H |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 22:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz