[Kaufberatung] Empfehlung für SQL-server

Rickyman

Enthusiast
Thread Starter
Mitglied seit
23.02.2010
Beiträge
446
Hi,
bin mir jetzt nicht sicher, ob der Beitrag wirklich hier zu 100% hinein gehört...

Ich benötige einen kleinen (von den Abmessungen) Rechner, auf dem Win7-64 läuft. Dort soll dann
die Erweiterung "Microsoft SQL Server 2008 R2 RTM – Express with Advanced Services" laufen.
Drei Win7-PCs werden auf die Datenbank dort zugreifen.


Was kann man da nehmen?

Preislich soll es natürlich auch im Rahmen bleiben. :)




Danke für die Tipps.
R
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
2008 RTM??? Wir sind doch beim SQL 2014 Server...

Im Prinzip kannst du nehmen was du willst. Solltest du schnell Platten und unmengen Ram nehmen.
 
Hi,
der Anbieter für die eigentlich Software hat die Version empfohlen.
Sind die neuen Versionen evt. kostenpflichtig?

Aber um noch mal auf die Hardware zurückzukommen...
Welcher Prozessor ist denn empfohlen?



Grüße
 
Wie viel Leistung brauchst du denn ? Wenn ich lese 3 Pc´s und ne SQL Datenbank dürfte das jetzt nicht weltbewegend viiel sein .
 
Ist korrekt, sollte nicht viel sein.

Kleine Baugröße, leise, günstig.

Ich denke RAM 4GB, HDD 1TB und ein I3(oder I5?) (oder weniger? )sollten reichen.
Da passiert nicht mehr.

Vorschlag?
 
Ich bezweifel das du wirklich einen i3 oder i5 brauchst. Denke Celeron/Pentium Richtung dürfte reichen.

Wie groß ist denn deine SQL Datenbank ? Mich wundern die 1TB etwas.
 
Da läuft doch sicherlich die Warenwirtschaft oder sowas drauf, oder?
Wenn du schon am Betriebssystem sparst (kein Server-System), dann nehme wenigstens einigermaßen anständige Hardware. Ein kleinen i3 würde ich empfehlen, dazu 8 oder 16 GB RAM und ein, zumindest Software-, Raid für die Datenbank, dass ein bisschen die Verfügbarkeit da ist.
 
Hm, OK, das waren Werte mal so ins Blaue...

Habe mal nachgeschaut. Die Datenbank ist jetzt 112.000KB groß und beihaltet deutlich weniger als 0,1% der zukünftig zu erwartenden Daten.
In wie weit die Datenmenge die Datenbank vergrößert ist mir nicht bekannt. Es scheint sich um eine Access-Datenbank zu handeln.

Grüße

- - - Updated - - -

Nachtrag: Es handelt sich um ein Praxis-Programm.

Für 2-3 Rechner ist mir eine echte Serverumgebung zu teuer.
 
Access? Was bitte soll das für ein Praxis-Programm sein? Sicherlich keines der großen Drei. Selbst die Marktführer in dem Bereich sind grauenhaft entwickelte Grütz-Software, aber Access? Selbst Medistar hat doch vor kurzem auf SQL (Oracle) umgestellt.

"Echte Serverumgebung" zu teuer... es handelt sich um eine Arztpraxis? Dann sollte das Geld aber eigentlich da sein. Wir haben auch kleine Arztpraxen als Kunde, auch Hausärzte, die können sich das auch alles leisten. ;)

Ich gehe mal eher davon aus dass hier durch mangelnden Sachverstand und/oder Geiz am falschen Ende gespart werden soll. Einfach mal das M6 Leasing kündigen und einen 4er fahren, reicht auch aus.

Außerdem gehe ich davon aus das du nicht wirklich weißt was du hier tust. Du weißt nicht mal um was für eine Datenbank es sich handelt, hast keine Ahnung von den eigentlichen Anforderungen, willst MSSQL-Versionen aus der Steinzeit betreiben und kannst dann auch nicht mal selbst Hardware zusammen stellen und fragst in einem Forum danach. Eine gefährliche Mischung.

Lass also die Bastellösungen und lass das jemanden machen der sich wirklich damit auskennt. Ein Desaster ist sonst vorprogrammiert.
 
Zuletzt bearbeitet:
Ich denke auch du solltest dir hier einen Partner mit Fachwissen organisieren.

Anbei trotzdem noch eine Hardwareempfehlung mit SSDs - Achtung nur eingeschränkter HP Support wegen Custom Hardware:


1 x HP ProLiant ML310e G8 v2, Xeon E3-1220 v3, 4GB RAM, 1TB HDD (724160-045)
1 x Kingston KTH-PL316ES/4G oder Kingston KTH-PL316ELV/4G
4 x Cremax Icy Dock EZConvert Air MB382SP-3B
1 x HP Smart Array P420/1GB FBWC, PCIe x8 (631670-B21)
4 x SanDisk X210 256GB, SATA 6Gb/s (SD6SB2M-256G-1022I) - RAID10
 
2008 SQL Server Express reicht völlig für solch ein solches Vorhaben aus, aber die Limitierungen beachten:
Max 10 GB pro Datenbank
Max 1 Core der CPU wird unterstützt
Max 1 GB RAM Nutzung

Reicht das wirklich?
 
Hallo an alle...

Danke für die vielen Tipps.
Und zur Beruhigung...ich baue das sicher nicht selber auf...da habe ich doch glatt Besseres zu tun.
Ich bin nur jemand, der gerne ebenfalls etwas an Informationen zusammenträgt.
Das sollte doch erlaubt sein oder ;) ?

Es ist auch keine Vielverdienerpraxis, sonder ein Heilpraktiker um den es hier geht.
( Und es ist auch kein M6 sondern ein E220 :) )
OK, Spass beiseite...

Es ist in der Tat eine SQL-DB und kein Acccess; mein Fehler bei der Recherche in der Dokumentation.
Macht ja auch wenig Sinn in Bezug auf meine Fragestellung.

Nach Aussage des Softwareanbieters wird natürlich nicht nur "alte" SQL-Version unterstützt,
diese sei aber vom Inhalt her für diese Zwecke schon mehr als ausreichend.
Außerdem gratis und dabei dann arm an Hardwareansprüchen.
Gut, muss ich so glauben.

Es braucht auch keine Hochverfügbarkeitslösung sein; Datensicherungen werden natürlich gemacht.


Wie gesagt, aufbauen macht jemand, der sich auskennt.

Grüße
 
Naja also sofern die Software SQL 2014 kann würde ich das verwenden.
Gibt es auch eine kostenlose Express Version von.
Generell solltest du darauf achten dass genug RAM zur Verfügung steht, SQL ist da doch sehr hungrig und krallt sich gerne alles was verfügbar ist.
Sofern häufiger Suchanfragen gestellt werden wird es ab einer bestimmten Datenbankgröße auch nicht mehr so lustig wenn du eine 1TB stromsparplatte verbaut hast.
Eine performante DB ist wichtig, sonst macht das Programm sicherlich keinen Spass.
 
Gibt es auch eine kostenlose Express Version von.
Generell solltest du darauf achten dass genug RAM zur Verfügung steht...
Das ist aber ein Widerspruch in sich, die Express Editions sind auf maximal 1 GB RAM beschränkt ;) auch die maximale Datenbankgröße ist zu beachten, maximal 10 GB.
 
Verdammt das stimmt ^^.
Da hast du natürlich recht......
Bin eben meine entwicklerversionen bzw enterprise gewohnt....
 
Hallo,
jetzt hatten mich die genannten Beschränkungen aber auch gewundert.
Nach Rückfrage ist es so, das nur die reinen Patientendaten ( also quasi Textinformationen ) in die DB kommen.
Alle Anlagen (Bilder, gescannte Dokumente u.ä. ) werden parallel gespeichert und intern verknüpft.
Somit schwillt die DB nicht so an.
Selbst mit 10.000ten Datensätzen ist die DB nur im MB-Bereich und nicht im GB-Bereich.

Schon besser oder?
 
Ja klar, dann passt die Express auf jeden Fall. Ich würde zumindest die 2012er oder neuer nehmen, alle anderen sind veraltet
 
Noch mal eine prinzipielle Frage zum Aufbau eines SQL-Servers:
Macht eine SSD Sinn oder in Bezug auf die Anwendung eher nicht?
 
Das kommt auf die Anwendung an ^^. (Wie viele Datenbankabfragen, cacht das Programm eventuell auch selbst etc)
Aber generell würde ich mal sagen dass die Anwendung ohne performante Datenbank auch nicht sonderlich gut laufen wird.
Die Details was du an Zugriffen zu erwarten hast können wir dir aber nicht nennen. -> Hersteller
Sofern die paar Euro für SSDs im Budget sind würde ich die mitnehmen.
 
Noch mal eine prinzipielle Frage zum Aufbau eines SQL-Servers:
Macht eine SSD Sinn oder in Bezug auf die Anwendung eher nicht?

150-300 IOPS (HDD) zu 8000-10000 IOPS (SSD)

Meiner Meinung lohnt für Applikationen (VMs, Datenbanken) immer eine SSD :-)


Konnte für diverse SAGE Programme mit SSDs erheblich die Performance steigern.
 
Wenn eine DB oft und viel auf die Platte zugreifen muss, dann läuft in der Anwendung grundsätzlich was schief.
 
Korrekt ^^
Sowas gibt es aber leider häufiger bei schlecht programmierter Software
 
Ja, weil kein Schwein sich Gedanken um ein vernünftiges DB-Schema macht. O-Ton eines Entwicklers: "wir konfigurieren es alles im Enterprise Architect, dann fällt da ein XML File, draus wird dann Java-Code generiert und noch die DB-Sachen". AAAAAAAAAAAAAAARRRRRRGGGGGGGGGHHHHHHHHHHHHH, HILFE. Indexes, braucht man das? Strukturelle Integrität und referentielle Integrität, wofür?
 
Zuletzt bearbeitet:
Ja, weil kein Schwein sich Gedanken um ein vernünftiges DB-Schema macht. O-Ton eines Entwicklers: "wir konfigurieren es alles im Enterprise Architect, dann fällt da ein XML File, draus wird dann Java-Code generiert und noch die DB-Sachen". AAAAAAAAAAAAAAARRRRRRGGGGGGGGGHHHHHHHHHHHHH, HILFE. Indexes, braucht man das? Strukturelle Integrität und referentielle Integrität, wofür?

Oder der Klassiker - Suchfeld Masken Abfrage für den Kunden und es wird immer die gesamte DB mit allen Tabellen komplett abgefragt :d
Zusätzlich keinen Index am Start und die wundern sich, warum das alle so lahm ist.
 
Hm,
OK, könnte mir einer das mal erklären? Bin da unerfahren und möchte das Prinzip verstehen.

Wie funktioniert denn so eine Abfrage?
Muss ich nicht entweder die ganze DB laden um sie zu durchsuchen, beziehungsweise muss ich nicht für jede Anfrage die DB durchsuchen?
Hier in meinem Fall geht es ja um eine DB mit Patientendaten. Das sind doch eigentlich recht viele einzelne Infos je Patient.
Und es greifen doch auch drei PCs auf die Daten zu. Dann muss doch jede Änderung sofort den anderen PCs auch zur Verfügung stehen oder?
Und muss ich nicht für jede Suche die DB durchsuchen?

Dann finden doch immer ständig Zugriffe auf die DB statt oder verstehe ich das falsch?

Bitte um Aufklärung (...in diesem Sinn).

Grüße und Danke
 
Ich kann Dir erklären, wie Oracle arbeitet, wie es SQL Server macht, keine Ahung, interessiert mich auch herzlich wenig. Wird aber auch halbwegs änlich sein.

Also, ein Beispiel: Du hast vier Tabellen:

1. Patient (id*, Geschlecht, Name, Vorname, GB-Datum)
2. Anschrift (id*, PLZ, Wohnort, Straße, Hausnummer, patient_id**)
3. Arztbesuch (id*, Datum, patient_id**)
4. Befund (id*, Diagnose, patient_id**)

*: Ist PrimaryKey der Tabelle, eindeutig, identifiziert den Datensatz
**: ForeignKey, damit wird der Datensatz der Parent-Tabelle referenziert.

Abfrage:
1. Jetzt willst Du wissen, wo die Frau Müller, geboren am 18.02.1979 wohnt:

Du greifst auf die Tabelle Patient zu, holst Dir die id und greifst mit der id dann in die Tabelle Anschrift rein (patient_id = id) oder in SQL ausgedrückt:

Code:
select pat.*, ansch.*
from 
	patient pat
	, anschrift ansch
where
	pat.id = ansch.patient_id
	and pat.geschlecht = 'Frau'
	and pat.Name = 'Müller'
	and gb-datum = '18.02.1979';

So, jetzt hast Du keinerlei Indexes auf den Tabellen. Oracle führt dabei ein FTS (FullTableScan) durch. Dabei wird jedes einzelne Datensatz der Tabelle angeschaut, bis der Richtige gefunden wird. Ist die Tabelle indixiert, sagen wir mal auf der Spalte gb-datum liegt ein Index. So kann die DB in den Index reingreifen und kann direkt die Datensätze finden, die der Bedienung (gb-datum = '18.02.1979') genügen. Das geht wesentlich schneller. Nun hat die DB einen Subset der Tabelle und muss sie noch nachfiltern, nach Name beispielsweise. So geht es dann mit den Indexes.

2. Angenommen, die Frau Müller ist von Müchen nach Mannheim umgezogen und wird nicht mehr von dem Arzt beobachtet. Die Patientenakte soll dabei gelöscht werden. Stehen die alle Constraints (diese sichern die Zusammengehörigkeit der Datensätze über die Tabellen hinweg oder auch in der Tabelle selber) rein ein delete auf die Haupttabelle, über die Kaskaden werden die drunterhängende Datensätze mit weggelöscht.

So funktioiert es, sehr vereinfacht gesprochen. Bei Oracle kommt da noch der Optimizer mit ins Spiel, aber davon erzähle ich jetzt nicht, das ist zu hoch dann.
 
Aha, ok...und in Bezug auf Deine Aussage "oft und viel auf die HDD zugreifen...". Soll die DB also eher komplett im Ram vom Server liegen oder nicht?
 
Wenn die Tabellen schön indexiert sind, dann muss die DB nur wenige Daten von der Platte lesen. Ist kein Index da, also im FTS-Fall, heißt es, dass die Tabelle gesamt in den Speicher geholt wird, was völlig unnötig ist.
 

Ähnliche Themen

Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh