Hallo zusammen!
Ich möchte eine wissenschaftliche Datenbank mit Bildern und Texten
erstellen. Sie sollte Schlagworte beinhalten und damit die einzelnen Bilder und Texte verlinken. Die Datenbank soll ins Internet gestellt werden. Welche Programme (die nicht zu teuer sind) eignen sich dazu? Kann man Access dafür verwenden?
Vielen Dank,
Simone
MYSQL zusammen mit PHP.
Das nimmt jeder.
Wenn Du das ins Internet stellen willst, brauchst Du einen Provider. Dieser bietet Dir (ab einem bestimmten Tarif) die Optionen an, dass Du MySQL und PHP benutzen kannst.
Dazu gibt es viele Baukästen, mit dern Hilfe man sich die Anwendungen zusammenbauen kann.
Gruß
Peter
Kann man Access dafür verwenden?
Ja, kann man. Allerdings benötigst du dann einen Provider, der anstelle von .PHP .ASP unterstützt und einen SQL-Server fährt, welcher mit Access-Tabellen umgehen kann.(das wird schwieriger zu finden sein!)
In der Regel läuft auf den Systemen der Provider jedoch PHP-Unterstützung und MySQL.
Man kann natürlich die Daten der Access-Tabellen nach MySQL portieren, aber dabei gibt es nicht selten Schwierigkeiten…
Sinnvoller wäre meiner Meinung nach, hier auf ein CMS (Content Management System) zu setzen, das durch die Benutzer über Browser gefüllt und gepflegt werden kann. Diese Systeme basieren in der Regel auf PHP mit einer MySQL-Datenbank.
Und wenn man sich im lokalen Netz erst mal ein CMS zum testen installieren will, kann man dafür Xampp als Serverpaket verwenden. (apachefriends.org/ist bereits alles vorkonfiguriert und muss nur auf dem Server aufgespielt werden!)
Hallo,
Du kannst sicherlich (fast) jeder Datenbank dazu nehmen, die Du bezahlen kannst 
Nur bei ACCESS sehe ich schwarz - weil die DB nicht skalierbar ist. Soll heissen, > 1GB ist Schluss.
MySQL, PostGre, Firebird etc. Kann man alles nehmen
Chris
Nur bei ACCESS sehe ich schwarz - weil die DB nicht skalierbar
ist. Soll heissen, > 1GB ist Schluss.
Maximale DB-Größe
A1.1 - A97 = 1 GB
A00 - A03 = 2 GB
…und wenn man die Bilder nicht direkt in der DB speichert, sondern nur den Pfad dazu, ist das eine Menge Holz.
ist aber Geschmackssache, weil die Bilder bei dieser Variante ausserhalb der DB vorhanden sein müssen.
Nur bei ACCESS sehe ich schwarz - weil die DB nicht skalierbar
ist. Soll heissen, > 1GB ist Schluss.Maximale DB-Größe
A1.1 - A97 = 1 GB
A00 - A03 = 2 GB
Das sind Theoretische Werte.
Zum defragmentieren / kompromieren (ein echter Gimick bei der „Datenbank“ Access) braucht man meist ca. 20% freien Platz.
…und wenn man die Bilder nicht direkt in der DB speichert,
sondern nur den Pfad dazu, ist das eine Menge Holz.
ist aber Geschmackssache, weil die Bilder bei dieser Variante
ausserhalb der DB vorhanden sein müssen.
Naja. DAS ist so nicht gesagt wurden. Außerdem - wozu eine Datenbank, wenn ich dann Bilder und Links DOCH selbst konsistent halten muss …
Chris
…und wenn man die Bilder nicht direkt in der DB speichert,
sondern nur den Pfad dazu, ist das eine Menge Holz.
ist aber Geschmackssache, weil die Bilder bei dieser Variante
ausserhalb der DB vorhanden sein müssen.Naja. DAS ist so nicht gesagt wurden. Außerdem - wozu eine
Datenbank, wenn ich dann Bilder und Links DOCH selbst
konsistent halten muss …Chris
… weil Access Bilder intern in einem verdammt speicherfressenden Bitmap-Format ablegt und ein JPEG von wenigen KB so schnell etliche MB verursacht, wenn man es in einer Datenbank direkt speichert!
… weil eine mit Bildern gefüllte Access-DB mit mehreren Hundert Bildern unheimlich langsam wird.
… weil das Komprimieren einer DB mit intern gespeicherten Bildern fast keinerlei Wirkung auf die DB-Größe hat.
daher wird auch regelmässig empfohlen, die Bilder eben nicht in der DB zu speichern, sondern nur den Pfad, der als Text relativ platzsparend ist.
Belib mal locker Jan …
… weil Access Bilder intern in einem verdammt
speicherfressenden Bitmap-Format ablegt und ein JPEG von
wenigen KB so schnell etliche MB verursacht, wenn man es in
einer Datenbank direkt speichert!
Na, na. Kommt ja auf den Entwickler an. Stream in ein OLE Feld. Da bleibt das JPEG so gross wie’s ist …
… weil eine mit Bildern gefüllte Access-DB mit mehreren
Hundert Bildern unheimlich langsam wird.
Das versteh ich _GARNICHT_. Hast Du das schon mal ausprobiert? Ich kann diese Aussage nach meiner Erfahrung nicht teilen.
Warum sollte die ACCESS DB langsamer werden? Das ändert nix am Zugriff via Indexen etc.
… weil das Komprimieren einer DB mit intern gespeicherten
Bildern fast keinerlei Wirkung auf die DB-Größe hat.
Das stimmt.
daher wird auch regelmässig empfohlen, die Bilder eben nicht
in der DB zu speichern, sondern nur den Pfad, der als Text
relativ platzsparend ist.
Naja.
Da stand „wissenschaftlich“.
Ich habe unter einem professionellen Einsatz halt ACCESS nicht empfohlen. Genauso wie ich es als unprofessionell halte, Bilder NICHT in die DB zu legen. Womit ich das bei bestimmten Aufgaben nicht ausschliessen möchte.
Aber wenn ich Daten verwalten sollte, bei dehnen Bilder ausgewertet und verknüpft werden mit wieder anderen Daten, dann nehm ich eine Datenbank, die mir ein professionelles Arbeiten ermöglicht. Stell Dir vor, es sollen auch Bildinformationen (Bitmuster etc.) behandelt werden …
Kurzum: Access ist für eine Heimatliche CD Verwaltung super. Wer dafür nen echten DB Server aufsetzt hat lange Weile.
Manchmal macht es auch Sinn Bilder extern zu lagern und nur die Links in einer DB zu halten. (Oft im Web benutzt) Aber optimal ist das nicht, aber manchmal nicht anders machbar. Tja und wenn es möglich ist, dann halt bitte ein echtes DBMS das mit meine Datenhaltung und die Datenauswertung abnimmt.
Chris
Belib mal locker Jan …
… weil Access Bilder intern in einem verdammt
speicherfressenden Bitmap-Format ablegt und ein JPEG von
wenigen KB so schnell etliche MB verursacht, wenn man es in
einer Datenbank direkt speichert!Na, na. Kommt ja auf den Entwickler an. Stream in ein OLE
Feld. Da bleibt das JPEG so gross wie’s ist …
Das JPEG bleibt schon, und die DB selbst explodiert…oder spielst du hier auf die Variante mit AppendChunk und GetChunk an?
… weil eine mit Bildern gefüllte Access-DB mit mehreren
Hundert Bildern unheimlich langsam wird.Das versteh ich _GARNICHT_. Hast Du das schon mal ausprobiert?
Oft genug, um es nicht mehr zu machen… Bei eingebundenen Bildern und der daraus resultierenden DB-Größe bleibt das nicht aus (solange man die herkömmlichen Wege geht, ohne programmiertechnisch die Trickkiste aufzumachen…)
… weil das Komprimieren einer DB mit intern gespeicherten
Bildern fast keinerlei Wirkung auf die DB-Größe hat.Das stimmt.
daher wird auch regelmässig empfohlen, die Bilder eben nicht
in der DB zu speichern, sondern nur den Pfad, der als Text
relativ platzsparend ist.Naja.
Da stand „wissenschaftlich“.
Ich habe unter einem professionellen Einsatz halt ACCESS nicht
empfohlen.
Access ist durchaus als „professionell“ einzustufen. Natürlich kommt es immer darauf an, was damit gemacht werden soll… und dass Access für verschiedene Einsatzzwecke nicht das geeignete RDBMS ist, ist auch nichts neues.
Kurzum: Access ist für eine Heimatliche CD Verwaltung super.
…professionelle Warenwirtschaftssysteme sind damit auch möglich, sogar im Multi-User-Einsatz.
Wer dafür nen echten DB Server aufsetzt hat lange Weile.
oder zu viele User und benötigt eine höhere Performance des Backends.
Manchmal macht es auch Sinn Bilder extern zu lagern und nur
die Links in einer DB zu halten. (Oft im Web benutzt) Aber
optimal ist das nicht, aber manchmal nicht anders machbar.
Als Beispiel mal
http://www.donkarl.com/FAQ/FAQ2Allgemein.htm#2.2
komisch, dass es unter Variante 1 abgelehnt wird, die Bilder in der DB zu speichern…Variante 2 wird von den wenigsten gewählt.
Letztendlich ist es jedoch jedem selbst überlassen, wie er in Access mit den Bildern umgeht.
Tja und wenn es möglich ist, dann halt bitte ein echtes DBMS das
mit meine Datenhaltung und die Datenauswertung abnimmt.
jep, wenn man dafür das nötige Kleingeld übrig hat. Ergo muss man sich erst überlegen, was gewünscht wird, dann informieren, welches RDBMS dafür geeignet ist, und zum Schluss erst kaufen…
Über das Thema kann man wohl ewig diskutieren, ohne ein gescheites Ergebnis zu erhalten. Aber das würde den Rahmen der eigentlichen Frage sprengen… davon sind wir ohnehin schon weit genug entfernt…