Wir müssen eine Datenbankanwendung
(Perl oder PHP) erstellen
(Adressen, Zusätzliche Daten, usw...)
also eben eine reine Datenbankanwendung.
Der Umfang wird so ca. bei 1 Mio. Datensätze
liegen (pro Tabelle, nicht für die ganze Datenbank).
Jetzt stellt sich die Frage, was nutzen wir.
MySQL
MS SQL-Server
anderes DB-System
Her mit den Info`s FÜR und WIEDER
eines der DB-Systeme.
Ach ja, die Anwendung selbst soll natürlich
unter Linux-Laufen.
Haut drauf mit den Komentaren
Torsten.E
Ich denke mal da gibt es schon noch ein paar Fragen zu klären.
1.) Wieviele Benutzer gleichzeitig ?
2.) Welche Antwortzeit ist die Untergrenze ?
3.) Wie komplex wird die Anwendung ?
4.) Was ist die erwartete Datenmenge ?
5.) Welche Ausfallzeit ist akteptabel ?
Die Frage ist einfach, was habt ihr vor. Mysql ist mit einer Adressdatenbank mit 1 Mio. Sätze sicher bei entsprechender Ausstattung nicht überfordert.
Wenn es aber um geschäftskritische, evtl. verteilte Anwendungen (Replication) geht, dann kommt man um eines der grossen System wie Oracle, DB2 oder auch MS-SQL-Server nicht herum. Nur diese bieten alle Features wie Transactionssicherheit, Sicherung im Laufenden Betrieb, Replication etc. an.
Oracle darf für Privat, bzw. Entwicklungszwecke kostenlos eingesetzt werden. Man zahlt nur (dafür aber ganz kräftig) für die Produktivversion.
Im Zusammenspiel mit dem Applicationsserver(iAS) lassen sich schnell und einfach Anwendungen entwickeln, die ohne jeden Aufwand auf jeder Plattform compiliert und ausgeführt werden können. E
Das Ganze ist jedoch nicht ganz billig, und mit Schulung,Produktionssoftware und allem drum und dran ist man so grob geschätzt ab 25.000 Euro aufwärts dabei.
Wie gesagt, für die Adressdatenbank ist das System völlig überzogen, wenn man aber sehr komplexe Anwendungen hat, so bietet Oracle sehr viele Möglichkeiten.
Wir haben hier zwei Szenarien im Einsatz:
Linux, mit mysql und php.
ca. 1-5 concurrent Users (gleichzeitig arbeitend, heisst nicht am Bildschirmsitzend und lesen, sondern die Beschäftigen die DB)
ca. 250.000 Datensätze und einfach gelagerte Anwendungen. 2-3 Tabellen nur verjoint, keine aussergewöhnlichen Suchkriterien.
Antwortzeiten bis zu 2 Sekunden.
Hardware PIII 500 , 512 MB und IDE System onboard. Suse 8,1
Linux mit Oracle
ca. 10 - 20 concurrent users
20 Mio. Datensätze
ca. 200 Rechner replizieren ihre Daten auf den Zentralrechner
Komplex gelagerte Abfragen, Antworzeit muss unter 5 Sekunden liegen.
1240 Attribute in 25 Tabellen.
Wir haben eine Kostenschätzung, die Langläufer verhindert (mit Oraclemitteln sind das 8 Zeilen Quellcode)
Ähnlichkeitssuche etc.
Hardware:
2 x PIII 900 2 GB RAM, SCSI160 RAID mit 400 GB. Suse 8,1
- - - - -
Geändert von Martin Ament (09-05-2003 um 15:16 Uhr)
Wer ist weisse ?
Der von jedem Menschen etwas lernen kann.
Hi Torsten,
den MS-SQL-Server wurde ich beim Einsatz unter Linux herausfallen lassen.
Macht irgendwie nicht so richtig Sinn, da die meisten Tools / Sprachen / Adminprogramme ja nur für Windows vorliegen.
Oracle ist sicherlich am sinnvollsten aber auch am aufwendigsten ( in Zeit und Geld).
Wie wärs den mit SAP-DB. Soll ja Oracle kompatibel sein. (kreativer Einfall, keine Empfehlung).
Auch Firebid / Interbase kann ich dir empfehlen. Das Mulitgeneration-Prinzip dieser Datenbank hat mir immer sehr viel freude bereitet. Auch im Betrieb hatte ich hiermit kaum Probleme.
Bei Oralce ist die ganze Sache halt deutlich Professioneller. Hierbei lernst du jedoch am meisten und kannst dieses am ehesten als Marktwert für dich selber wiederverwenden. Aber es ist auch ein ganz schöner Berg an Wissen der erst einmal geschluckt werden muss.
Grüße
- Mike
Hallo!
Von SAP-DB kann ich nur abraten... nach meinen Erfahrungen schlecht zu administrieren und nicht sehr stabil.
Eventuell sollte man mal Postgres ins Auge Fassen.
Man sollte auch nicht vergessen, dass DB2 und Oracle imense Hardwareanforderungen mit sich bringen.
Ich würde einfach mal ein wenig Arbeitsszeit investieren und auf möglichst vielen Systemen Tests anstellen und die Kriterien wie Transaktionssicherheit (und andere die schon genannt wurden) in die Überlegungen mit einbeziehen.
Letztendlich ist die Anzahl der Datensätze nicht entscheident, sondern wie auf die Datensätze zugegriffen wird.
Bei 1 Mio Datensätzen, die mit einem einfachen SELECT ohne große Joins auskommen sollte MySQL keinerlei Probleme haben!
Auch wenn MS SQL und Linux auf den ersten Blick absurd erscheinen sollte man nicht vergessen, dass MS SQL ein hervorragendes Datenbank System ist, welches noch dazu sehr komfortabel zu administrieren ist.
HIER FEHLT ABER WAS: Interbase/Firebird. Linux-Server mit IB/FB Workstations mit M$
Gruß
Hansa
Erst mal Danke an die ganzen Anregungen hier.
Die Anzahl (hausinterner) Benutzer wird sich zwischen 5 und 10 bewegen,
zusätzlich kommt eine nicht bekannte Anzahl an Benutzer über das Internet.
Mehr als 30 User gleichzeit denke ich aber werden es nie werden.
Die Abfragen über das Internet werden eher einfach sein, da hier nur
z.B. Adressen bearbeitet werden.
Aber ich sehe da schon, wenn man den Usern den kleinen Finger gibt,
wollen Sie gleich alles.
Auf was ich jedenfalls keine Lust habe ist das FrontEnd 2 mal entwicklen,
einmal für`s Web und einmal für uns hausintern.
Das mit den Tests ist gar nicht so einfach:
1. hab ich derzeit nur MySQL und MS SQL-Server Developer hier
2. da ich die DBMS-Systeme ja nicht gut kenne, lassen sich die Unterschiede
vermutlich auch gar nicht so einfach erkennen.
Also ruhig weiter Gedanken hier posten, ich schau mich auch anderweitig
um, damit ich mir ein Bild machen kann, wo ich ganze Sache "draufpack".
Ein schönes WE an alle aus dem Allgäu
Torsten.E
ich arbeite mit mysql und ms-sql...
mysql ist wohl ausreichend schnell für Deine Anforderungen. Ich habe auch bei komplexen Abfragen bisher keine Performanceprobleme feststellen können.
- Hotline-Datenbank mit > 20.000 Calls und weiterführenden Daten
- Gewinnzahlen/Quoten mit allen Daten seit es Lotto gibt. Wird ständig weiter befüllt und ist sehr schnell
In ms-sql haben wir komplexe Prozeduren für datenimporte usw. gemacht. Ist auch recht performant, aber eben nur bei ausreichender Hardware. Das eigentliche prob mit dem sql-server von ms ist das Betreibssystem auf dem das ding läuft
- statistische DB mit mehreren Mio Datensätzen
Der Einsatz von ms-sql-sserver ist bei uns historisch gewachsen. ich würde der mysql auch die statistischen Daten problemlos anvertrauen. Allerdings steckt einfach zu vielk entwicklungsaufwand auf ms-seite... Ausserdem fehlen der mysql im Augenblich noch ein paar entscheidende features:
-Subselects
-Views
-Stored Procedures
Wird aber alles besser...
es macht auf alle Fälle Sinn, möglichst datenbankunabhängig zu entwickeln. Damit besteht einfach die Möglichkeit das DBMS zu wechseln, wenn es den Anforderungen nicht (mehr) genügt
Geändert von elrond (21-05-2003 um 09:09 Uhr)
"Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)
Schon mal PostgreSQL ins Auge gefasst?Original geschrieben von elrond
ich arbeite mit mysql und ms-sql...
Der Einsatz von ms-sql-sserver ist bei uns historisch gewachsen. ich würde der mysql auch die statistischen Daten problemlos anvertrauen. Allerdings steckt einfach zu vielk entwicklungsaufwand auf ms-seite... Ausserdem fehlen der mysql im Augenblich noch ein paar entscheidende features:
-Subselects
-Views
-Stored Procedures
Kann alle diese Dinge (und viel mehr: ist ein objektrelationales System).
Auch Transaktionsserialisierbarkeit ist mit MultiVersionConcurrencyControl
(MVCC) recht clever implementiert.
noch nicht, da ich mit dem was ich habe relativ zufrieden bin...
"Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)
Berechtigungen
Zitieren
Lesezeichen