Einsatzzweck? Produktiv und wenn es nicht MySQL-kompatibel sein *muß*, ist von ALLEM aus der Richtung abzuraten. Für die kleine Umgebung kann man buchstäblich auf alles ausweichen, sei es ein MS SQL Server in der Express-Variante (genügt für "klein" immer) oder eine Oracle-Instanz (diese aber ohne Support!) in beliebiger Größe oder sowas wie Postgres aus dem Open Source Segment.
Privat kann man natürlich nehmen, was man will.
DBMS auf Raspberry würd ich gar nicht erst probieren. Schon deswegen nicht, weil der Datenträger dafür denkbar ungeeignet ist. Da reden wir noch nicht mal von der CPU-Power und vom verfügbaren Arbeitsspeicher.
Fürs DBMS kann man irgendein Linux oder BSD nehmen, auch gleich als fertige Appliance, die man nur noch als VM ausführen muß (zB via docker). Das spart den Overhead durch GUIs (sieht man eh nicht).
Für kleine Datenbanken spricht absolut nichts gegen eine SSD, aber es sollte (wenn möglich) trotzdem eine eigene sein. Nicht vergessen, daß Daten im DBMS nochmal extra kritisch sind, daher Recoverymöglichkeiten im Auge behalten, zB indem man vollständige Logs auf einen zusätzlichen Datenträger schreibt (also an dieser Stelle einen dritten) und diese regelmäßig wegsichert.
.
Bei CPUs für DBMS ist eher auf Threadanzahl und Cachegröße zu schauen als auf Singlethreadperformance - je mehr desto besser, aber für so kleine DBMS muß man das natürlich nicht besonders übertreiben.
Dasselbe gilt für RAM. 16GB alles inclusive sollten es für den produktiven Einsatz unter Windows schon sein (mit GUI). Ohne GUI genügen 8GB für kleine Umgebungen, aber auf Kante fahren sollte man natürlich trotzdem nicht - wenn mehr RAM erforderlich werden sollten, dann müssen die auch nachgerüstet werden können.
Für den nichtproduktiven Betrieb kann man sich so eine kleine Datenbank natürlich buchstäblich irgendwo dazuklatschen. Ich will nicht sagen, SSD wäre Pflicht - ist sie nicht -- aber man profitiert trotzdem ungemein davon; "normale" DBMS im Privatsektor laufen nicht im RAM, sondern direkt von der Platte und da haben HDDs mehr oder weniger buchstäblich verloren. (Einfach das DBMS für in-memory konfigurieren geht natürlich, erfordert aber *ausreichend* viel RAM *und* sorgt dafür, daß die Kiste effektiv nicht mehr auszuschalten geht, was im Privatsektor eher ungünstig ist.)
Was die Netzwerkkonfiguration angeht: ist halt auch die Frage, was genau der Einsatzzweck ist, aber wenn die Anwenderzahl genauso überschaubar ist wie die Datenbankgröße, dann muß man da nicht viel Federlesen machen:
- Überlegen, wie viele das sind
- Switch einkaufen mit genügend vielen Ports (und noch ein paar extra für freie Kapazitäten sowie einem Port für die Kommunikation mit dem Router)
- PCs alle an den Switch
- Switch an den Router
- ich würd persönlich noch DNS und DHCP irgendwo einrichten, damit man sich nicht mit IP-Adressen rumärgern muß, aber prinzipiell ist DNS an dieser Stelle noch nicht zwingend und die IP-Clientkonfiguration kann über den DHCP im Router laufen, unter der Annahme, daß man nicht mehr konfigurieren muß/will, als der DHCP-Dienst dort zuläßt.
Und schon sollte die ganze Sache laufen.
Wenn außerdem noch ein Netzwerkspeichergerät in der Warteschlange steht, dann kann man auch drüber nachdenken, eines einzukaufen, was ausreichend performant ist - Bauform wär erstmal egal (Fertig-NAS oder PC). Da drauf kann man dann zB per Docker die benötigten Dienste einfach einrichten, und zwar so, daß die sich auch nicht in die Quere kommen. Dann spart man sich die zusätzliche Hardware. Die Gesamtkosten bleiben aber trotzdem in etwa dieselben.
