Projektierung: Bauteildatenbank

[Sven P. (Gast)]

Huhu,

ich hab angefangen, (noch) eine Bauteildatenbank zu programmieren. Dazu 
möchte ich nun ein paar Meinungen und Anregungen einholen.

Beschreibung/Status:
- SQL-basierter Datenbestand, z. Zt. MySQL
- in PHP geschrieben
- auf Mehrbenutzerbetrieb ausgelegt
- Bauteilkategorien verschachtelt angeordnet
- Bauteilparameter beliebig konfigurierbar
- vollparametrische Suchfunktion, Sortierung
- beliebige Lieferanten mit Preisen hinterlegbar
- zusätzliche Ressourcen (Datenblätter, Links) anhängbar

Wozu ich nun Voschläge bräuchte:
- Welche Kategorien soll ich einbauen?
- Entsprechend: Welche Bauteilparameter sollen hinterlegt werden?
- Hat jemand eine Idee, wie man automatisiert aus Reichelt/Farnell/... 
aktuelle Preise rausorgelt...?

Die Chose steckt noch tief in den Kinderschuhen, von daher geb ich 
erstmal nur Bilder frei.
Ich möchte das Projekt später unter eine freie Lizenz stellen.

Na dann, bin für alles offen :-)

http://e.svgweb.de/pdb

MfG Sven

[Chris (Gast)]

> - in PHP geschrieben

Anregung: Andere Sprache in Erwägung ziehen. :)

PHP ist heutzutage nicht mehr unbedingt erste Wahl bei Web-Projekten. 
Zum Beispiel Python und Ruby (on Rails) erlauben eine deutlich 
effizientere Entwicklung. Vor allem so ein Hobby-Projekt bietet sich 
IMHO dafür an, sich mal eine andere Sprache anzueignen.


Aber falls du schon recht große Code-Mengen geschrieben hast, dann steht 
das natürlich nicht mehr für die aktuelle Version zur Diskussion.



Damit es nicht nur um die Wahl der Programmiersprache geht, noch ein 
anderer Aspekt: Meiner Meinung nach ist so ziemlich das allerwichtigste 
bei so einem System die einfache Eingabe und Aktualisierung der 
Datenbestände. Denn nur wenn auf das User-Interface viel Wert gelegt 
wird und es sehr effizient zu bedienen ist, wird man die Bauteil-Daten 
auch wirklich aktuell halten.

Um ein konkretes Beispiel zu nennen, was ich damit meine: Man könnte 
z.B. mal ausprobieren, ob ein Schieberegler mit nur wenigen festen 
Positionen effizienter ist als ein Textfeld, um die Widerstand-Toleranz 
einzugeben.

[Frank E. (Firma: Q3) (qualidat)]

Zum Thema Programmiersprache:

Aus Sicht des Anwenders/Benutzers ist es völlig irrelevant, in welcher 
Programmiersprache ein Tool verfasst ist, so lange das keine merklichen 
Auswirkungen auf die Installation und Handhabung hat.

Was ich potentiellen Nachnutzern unbedingt ersparen würde: Sie dazu zu 
nötigen, irgendwelche zusätzlichen Interpreter, Player oder "virtual 
machines" zu installieren, bevor die Software genutzt werden kann.

Wenn daran kein Weg vorbeiführt, dann muss es wenigstens einen 
"Rundum-Sorglos-Installer" geben, der auch im Falle einer 
De-Installation all den Kram wieder mitnimmt. Nicht jeder hat Lust beim 
Testen einer Software erst ewig an Umgebungsvariablen, Ordnern, Pfaden 
oder Registry-Einträgen herumzubasteln.

Zum Schluss würde ich noch über den Punkt "plattform-übergreifend" 
nachdenken. Die Zeiten von "eine Milliarde Fliegen kann sich nicht 
irren" sind nämlich zum Glück allmälich vorbei :-)

Frank

[Sven P. (Gast)]

Danke für die Kritik :-)
Also:

Chris:
Ich habs mir mit der Sprache nicht leicht gemacht >_>

Python käme infrage, damit hab ich schon gearbeitet. Allerdings finde 
ich PHP bequemner (<?php ... ?>). Geschwindigkeitsmäßig usw. tun sich 
beide nichts, also ganz klar reine Geschmackssache.

Ruby habe ich noch nie programmiert, ich hab aber damals die Vorstellung 
von RoR auf der CeBIT gesehen. Damals hatte man Ruby allerdings eine 
miserable Performance nachgesagt, hauptsächlich, weil direkt der 
Syntaxbaum ausgeführt wird, anstatt (wie PHP) zuerst Bytecode zu 
erzeugen. Ob sich daran etwas geändert hat, weiß ich nicht :-)

PHP platzt zwar auch mittlerweile aus allen Nähten und es sieht und sah 
teilweise katastrophal aus (verwaiste Module und all so ein Zeugs), aber 
PHP wird ja zur Zeit ordentlich aufgeräumt...

Ich komme ansonsten immer noch mit einer C-ähnlichen Syntax am besten 
parat, logisch, ich programmiere ja auch sonst immer C.
Zuletzt finde ich PHP immer noch auf mehr Servern als RoR oder Python, 
aber auch das mag ein subjektiver Eindruck sein.

Zusammenfassend: Ich hab PHP genommen, weil ich faul bin und schon 
einiges damit gemacht hab -- also reine Geschmackssache. Es bestehen 
mittlerweile schon reichlich Quelltexte, sodass ich einen Umstieg 
vermeiden möchte.


Frank Esselbach wrote:
> Was ich potentiellen Nachnutzern unbedingt ersparen würde: Sie dazu zu
> nötigen, irgendwelche zusätzlichen Interpreter, Player oder "virtual
> machines" zu installieren, bevor die Software genutzt werden kann.
Es braucht ja Gott sei Dank in der Kombination nichts installiert zu 
werden, simples Kopieren reicht aus; im Zweifelsfall läuft die Sache 
auch z.B. direkt vom USB-Stick.
Entsprechend beschränkt sich die Deinstallation auf ein Löschen eines 
Ordners.

> Zum Schluss würde ich noch über den Punkt "plattform-übergreifend"
> nachdenken. Die Zeiten von "eine Milliarde Fliegen kann sich nicht
> irren" sind nämlich zum Glück allmälich vorbei :-)
Joa, da hab ich drüber nachgedacht. Aber warum sollte ich mir weitere 
Gedanken darum machen, wenn ich mit PHP, MySQL und einem Webserver 
bereits sämtliche Plattformen ohne Mehraufwand erschlagen hab?

Sollte es später notwendig werden, die PlattformUNabhängigkeit 
aufzugeben, kann ich dich aber beruhigen: es wird für Linux/POSIX 
weiterenwickelt, Windows müsste ich mir erst kaufen...

[Mehmet K. (mkmk)]

Soweit ich weiss, ist MySQL nicht frei von Lizensgebühren. Weshalb ich 
schon seit laengerem nur noch Firebird einsetze.

[Marc (Gast)]

@Mehmet: Mysql ist Lizensgebuehren frei in der GPL version.

Gruss
Marc

[Sven P. (Gast)]

Korrekt, bei MySQL hängts vom Einsatz ab. Ansonsten bemühe ich mich, 
ANSI-SQL zu verwenden, damit dürfte es dann auch einfach auf Firebird, 
Postgres und andere zu portieren sein.

[Chris (Gast)]

Für eine private Bauteildatenbank könnte sich evtl. auch SQLite eignen 
[1]. Das bringt noch weniger Installationsaufwand mit sich als MySQL, 
weil kein Datenbank-Server gestartet werden muss.

[1] http://www.sqlite.org/