Grafik in Datenbank speichern

Auf keiner von Moses Steintafeln steht, dass es Replikation nur für RDBMS geben darf. Man kann sich relativ unaufwändig z.B. mittels RSYNC selbst einen Mechanismus stricken, oder sich nach Zusatzsoftware/Modulen umsehen. Binärdaten in relationalen Datenbanken abzulegen ist ein denkbar uncooler Workaround, zumal DB- und Application-/Web-Server gerne getrennt werden.

Du schrubst allerdings nichts über dein Szenario und so könnte man sich nun endlos in Spekulatius ergehen - immerhin ist bald Weihnachten! ;)

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay

Wahrscheinlich werden bei deinen Anwendungen die Grafiken nicht in der datenbank gespeichert, sondern nur die URL s und Ordner, wo sie sich befinden.
Wenn es so waere, dann wäre es ein alter Fehler, den ich oft für verschiedene Anwendungen lese.

Wahrscheinlich musst Du nur den Bilderordner auf den neuen server überspielen und die Pfade anpassen. Wirklich ,-- ich habe noch keine Anwendung gesehen, bei denen die Bilddateien selbst in der datenbank gespeichert waren.

Forum fuer Esoterik Interessierte Heilsteine .Info < br />
Schmuck und Edelsteine

Das ist aber genau, was er nicht will. Mich würde nur interessieren warum.

Natürlich kann man auch Bilder in einer DB ablegen. Rein in den BLOB und fertig. Nur fällt mir persönlich kein Szenario ein, wo das unbedingt notwendig/sinnig wäre.

BTW:
Das interne Handling von BLOBs ist auch unterschiedlich in den RDBMS gelöst. Bei PostgreSQL wird beispislweise intern auch wieder als Datei abgelegt und nur ein Verweis erzeugt. Aus Sicht der SQL-Abfrage ist das allerdings transparent.

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay

Ich glaubs ja immer noch immer nicht, das er DAS will.
Ich glaub einfach, er ist sich nicht sicher was er will, und jetzt will er vielleicht dann auch eher das Handling wie s meistens mit den Bildern gemacht wird.
...smile... gruss
manne

Forum fuer Esoterik Interessierte Heilsteine .Info < br />
Schmuck und Edelsteine

Doch, Du hast recht, DAS wollte er schon. Es war präzise formuliert. War mein Fehler.
dennoch Gruesse manne

Die Anfrage ist im Moment nur ein theoretisches Abchecken ob Drupal zum Einsatz kommen könnte. DMZ mit Firewall, Loadbalancer, 2 Webserver (Live-Server), Firewall zum Intranet. Datenbankserver und Webserver für Redakteure im Intranet. Live-Server greifen auf Datenbankserver im Intranet zu. Redakteur-Webserver auch.

Die Daten im Intranet müssen unter allen Umständen geschützt werden. Es werden zusätzlich Daten aus den internen Geschäftsdatenbanken im CMS benötigt. Deshalb muss der Zugriff von außen zur Verfügung gestellt werden. Je mehr Ports aufgemacht werden, um so unsicherer wird die ganze Sache. Zu den oben genannten Sicherheitsmaßnahmen kommen noch diverse nicht genannte hinzu.

Das Speichern der Bilder in der internen Datenbank erübrigt das Öffnen eines zusätzlichen Ports und das Löschen / Hinzufügen von innen nach außen auf 2 Server. So ein Sch.. wird zu Zeit eingesetzt und macht nur Ärger.

vg
myOtto

Ich kenne eure aktuelle Synchronisationslösung nicht, aber formuliere es mal so:
Wenn jemand kein Auto fahren kann, ist das kein Beweis dafür, dass Autos als Fortbewegungsmittel ungeeignet sind. Es beweist lediglich dass der Fahrer nicht taugt ;)

Wenn ihr einen LB einsetzt, dann weil ihr entsprechend Last auf den Webservern erwartet. Wenn der DB-Server davon getrennt ist, erzeugt die Ablage von Binärdaten in der DB massiv erhöhten Traffic zwischen DB-Server und Web-Servern. Da wird das Netzwerk schnell zum Bottleneck (wenn nicht bereits der DB-Server selbst), noch dazu wenn dazwischen eine FW (beschränkt durch mangelnde Leistung ggf. die Bandbreite und erhöht die Latenz) hängt, weil die DB im Intranet steht.

Wenn ihr Zugriffe von außen aufs Intranet verhindern wollt, hat der Live-DB-Server nichts im Intranet zu suchen. Die sinnigste Möglichkeit ist von innen benötigte Daten (und nur diese) auf einen außerhalb / in der DMZ liegenden Server zu schieben und jegliche Zugriffe von außen auf interne Server zu unterbinden - ohne Ausnahme! Alles andere ist sicherheitstechnischer Muckefuck.

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay

Wir sollten diese Diskussion an dieser Stelle beenden. Danke für deine Meinung.

Sorry, aber entweder man will Sicherheit oder nicht. Da ist bestenfalls sehr wenig Spielraum für Kompromisse.

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay

Der Ton in dem Sie diskutieren ist evtl. auf einem Schulhof üblich. Mich stößt so eine Art der Kommunikation ab. Ich möchte mit Ihnen auch nicht weiter diskutieren. Ende!

Tipp: Personalverantwortliche scannen das Internet bei Bewerbungen. Wenn dabei so eine Diskussion gefunden wird, landet die Bewerbung sofort in der Rundablage.

Danke für den Tipp, aber Arbeitgeber bekommen mich so wie ich bin und ungeschminkt. Bisher stets "zur vollsten Zufriedenheit".

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay