nicht angemeldet
Vorhandene db:Eigener Server oder Webhoster?
Was meint Ihr:
Ich habe eine vorhandene db, die ich in ein zukünftiges Web-projekt einbinden soll. (entweder access, könnte auch auf den im haus befindlichen ms sql-server portiert werden.)
bis jetzt wurde die db nur im intranet verwendet. das künftige firmenweb soll auf einen externen webhoster kommen. soll ich die db auch dort installieren, oder über den eigenen server anbinden. wie sieht es da mit der sicherheit aus? (wenn die db nur vom der ip des webhosters aus angesprochen werden kann, müßte es von der sicherheit her nicht so dramatisch sein, oder?)
es ist nämlich so, dass die db eiige gb erreichen kann, und deswegen ist das betreiben am fremden host wahrscheinlich auch eion wenig kostspielig. oder würdet ihr die ausgaben für sicherheit am eigenen server höher einschätzen?
ich bin kein db-experte, den müßten wir dann natürlich hinzuziehen, ich möchte nur mal vorab klären, welche vor- und nachteile die beiden varianten haben. danke für eure hilfe!
Paul
-
Hello,
Deutsche Firmen achten viel zu wenig auf die Bewahrung ihrer Geschäftsgeheimnisse.
Wenn diese DB also Informationen enthält, die nicht für Jedermann bestimmt sind, und erst recht nicht für die Amerikanische Konkurrenz, dann solltest Du sie hübsch im Inselbetrieb halten. In dem Moment, wo man mit einem #######-Host (zensiert) an ein (öffentliches) Netz geht, hat man auch die Möglichkeit geschaffen, das Ding aufzumachen.
Aber auch, wenn die Daten einzeln nicht sensibel sind (also für die Amis wertlos), dann sind sie als Sammlung für den lokalen Markt wahrscheinlich doch etwas wert. Um nun zu verhindern, dass Datensammlungen einfach von anderen gegrabbed werden, ist ein Mix aus Maßnahmen notwendig. Selbstverständlich gehört ein ausgefuchstes Controlling dazu.
Wenn man einen vernünftigen Provider kennt, über dessen Umfeld man sich schon _persönlich_ informiert hat (hinfahren, zeigen lassen, Gespräche führen), kann man sicher seine DB dort hosten, ssl oder andere Techniken vorausgesetzt. In die DB hat man dann aber auch "Maßnahmen" eingebaut, um Missbrauch nachweisen zu können.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Mahlzeit,
Deutsche Firmen achten viel zu wenig auf die Bewahrung ihrer Geschäftsgeheimnisse.
Sagen wir so: Viel zu viele Verantwortliche in deutschen Firmen achten zu wenig auf Sicherheit ihrer Daten. Und im Vorfeld von Projekten wird fast nie über diese Aspekte nachgedacht. Woran liegt das? Sicherheit ist auch Managementsicht kontraproduktiv[tm]!
Was meinst du mit Inselbetrieb? Im eigenen Intranet den DB Server hinstellen und ans Internet binden und dann einen entfernten Webserver betreiben der sich seine dynamischen Daten quer durch's Netz via zig Zwischenstationen zieht?
Halte ich für tödlich, auch gewähnter VPN Sicherheit.In dem Moment, wo man mit einem #######-Host (zensiert) an ein (öffentliches) Netz geht, hat man auch die Möglichkeit geschaffen, das Ding aufzumachen.
ACK.
Tom, es sind nicht immer nur die Amis, schau mal gen Osten, da gibt es ein Land wo mehr Internetkriminalität herrscht als in ganz Europa zusammen. Die haben ziemlich viele Einwohner dort und verfahren nach dem bekannte Motto: Überholen ohne Einzuholen :-)
Man liest sich.
Frank-
Hi,
Sicherheit ist auch Managementsicht kontraproduktiv[tm]!
Oh ja *sigh*
Die Mauern, die man da mitunter einrennen muß würden sogar noch einem Atombunker zur Zierde gereichen.Was meinst du mit Inselbetrieb? Im eigenen Intranet den DB Server hinstellen und ans Internet binden und dann einen entfernten Webserver betreiben der sich seine dynamischen Daten quer durch's Netz via zig Zwischenstationen zieht?
Halte ich für tödlich, auch gewähnter VPN Sicherheit.Es ist, auch wenn Du das nicht glauben magst (alleine aus dem Bauch raus würde ich das aber auch nicht, klar), in diesem Fall eine anständige Möglichkeit. Zumindest hinsichtlich der Sicherheit.
Hier handelt es sich immerhin um eine Datenbank die nur auf einem einzigem Betriebsystem lauffähig ist (die Meldung letzthin, das MS seine SQL-Datenbank auch offiziell auf andere OSe portieren möchte halte ich für einen Aprilscherz. Auch wenn das keiner war). Beide werden von einer Firma produziert die seit ihrem Bestehen immer wieder Beweise dafür liefert, das sie sich einen Dreck um Sicherheit schert.
Alleine schon deswegen muß eine gute Absicherung erfolgen. Physische Trennung ist da schonmal sehr gut. Die würde hier dadurch erfolgen, das der Zugang über den Webserver erfolgt, die SQL-Abfragen eine Klasse 3 Firewall (L3/4 u. L7 getrennt) durchlaufen und dann auf dem DB-Server landen. Der Transfer kann mittels passender Technik (IPSec u.a.) sehr preiswert gesichert werden. Wo die Kisten stehen ist dadurch aber auch egal und kann frei ausgesucht werden. Da anzunehmen ist, da bei Bestand einer großen DB auch das Wissen zur Pflege da ist (ob zugekauft oder eigen ist hier egal), sollte die DB schonmal am Ort verbleiben. Da aufgrund der Verschlüsselung des Transfers und des damit verbundenen Problems des Erhalts der P2P-Sicherung sollte die FW zwischen DB und Webserver auch am Ort verbleiben.
Nur: lohnt es sich dann noch ein externer Webserver?
Wenn im Haus kein Fachwissen über Webserver zu erhalten ist: ja, ansonsten sind die Kosten für den Transfer von der DB zum Webserver einzukalkulieren (Wenn die Antwort von der DB keinerlei(!) Nachbearbeitung erfordert, kann man natürlich auch direkt zurücksenden), der natürlich auch noch vom Webserver zum Kunden anfällt (Größe je nach Weiterverarbeitung natürlich stark schwankend) sowie die Kosten für die Pflege der FW. Hauptposten sind aber natürlich die Kosten, die bei einem evt Schaden anfallen, sei es nun Verlust der Daten/Geheimhaltung oder gar Veränderung der Daten.Mehr Tips kann man aus Deinen _sehr_ mageren Informationen nicht rausziehen.
Tom, es sind nicht immer nur die Amis, schau mal gen Osten, da gibt es ein Land wo mehr Internetkriminalität herrscht als in ganz Europa zusammen.
Die können aber meist mit den Geschäftsdaten nix anfangen und bieten die dem Meistbietenden an. Das sind, so gern es mir leid täte, meistens die Ammies.
Die haben ziemlich viele Einwohner dort und verfahren nach dem bekannte Motto: Überholen ohne Einzuholen :-)
Darin waren sie ja schon immer sehr gut. Da es zudem allen nützt ist da auch nix gegen zu sagen.
so short
Christoph Zurnieden
-
Hi Christoph,
Mehr Tips kann man aus Deinen _sehr_ mageren Informationen nicht rausziehen.
Aus der Original-Frage oder aus meiner Antwort? (Wenn letzteres, dann bitte warum dieses??)
Okay, VPN/IPSec mag in dem Moment noch ein probates Mittel sein, um etwas Sicherheit zu schaffen. Unwohl ist mir dennoch, geschäftskritische Daten quer durch das Internet zu schaufeln, zumal ja auch (wie immer) nicht gilt, dass TransportationCost = 0 bzw. Latency = 0 ;-)
Einen eigenen Webserver im Haus mit zu plazieren, 'türlich das liegt nahe, jedoch passt es dann mit den Verfügbarkeitsanforderungen an die Applikation noch. Information wie intensiv die Benutzung sein soll wurde ja nicht gegeben, nur dass die DB GBs-groß sein kann.
Die können aber meist mit den Geschäftsdaten nix anfangen ...
mag sein, kommt auf die Daten an :-)
immer wieder Beweise dafür liefert, das sie sich einen Dreck um Sicherheit schert.
Kann ich nicht 100% unterstützen. Wo ich dir zustimmen kann, dass MS in der Vergangenheit kein besonderes Augenmerk (verlängert ja auch den Produktentwicklungszyklus :-)) auf Sicherheit gelegt hat. MS ist mittlerweile sehr wohl engagiert, wenn es um die Sicherheit ihrer Produkte geht (man will ja auch mehr verkaufen, speziell im Business-Bereich), vielleicht weniger bei den Heimanwenderprodukten und eher bei den Serverproduktion, aber es wird deutlich mehr Aufwand betrieben als noch zu Windows 2000 Zeiten. Vergleiche mal die Häufigkeit von sicherheitskritischen Fehlern zwischen Windows 2000 und Windows 2003. (Ich möchte dieses Thema jetzt aber nicht wieder aufkochen)
MS SQL Server auf einem Unix, das wäre mal ne interessante Sache ... kann mir auch ungefähr vorstellen wieso. :-)
Na denn, schönen Samstag noch :-)
Frank-
Hi,
Mehr Tips kann man aus Deinen _sehr_ mageren Informationen nicht rausziehen.
Aus der Original-Frage oder aus meiner Antwort? (Wenn letzteres, dann bitte warum dieses??)
Aus der Originalfrage natürlich, 'tschuldigung.
Okay, VPN/IPSec mag in dem Moment noch ein probates Mittel sein, um etwas Sicherheit zu schaffen. Unwohl ist mir dennoch, geschäftskritische Daten quer durch das Internet zu schaufeln, zumal ja auch (wie immer) nicht gilt, dass TransportationCost = 0 bzw. Latency = 0 ;-)
Ja, nur aus dem Bauch raus würde mir das natürlich auch nicht schmecken. Aber es spielen da so viele Faktoren eine Rolle, das es in einigen Fällen passen würde. Das sind noch nicht einmal irgendwelche abstrusen Konstellationen, sondern ganz normale wirtschaftliche und/oder sicherheitstechnische Gründe.
Einen eigenen Webserver im Haus mit zu plazieren, 'türlich das liegt nahe, jedoch passt es dann mit den Verfügbarkeitsanforderungen an die Applikation noch. Information wie intensiv die Benutzung sein soll wurde ja nicht gegeben, nur dass die DB GBs-groß sein kann.
Naja, an GB große DBs mit Access, wie angedeutet, glaube ich eh nicht. Das mag funktionieren, aber auch nur mit sehr vielen zugedrückten Augen und wirklich nur schierer Größe und sonst keinerlei Komplexität.
Die können aber meist mit den Geschäftsdaten nix anfangen ...
mag sein, kommt auf die Daten an :-)Ja, klar, aber bei den meisten Daten wäre eine nicht unerhebliche finanzielle Vorleistung zur Nutzung nötig, da ist es deutlich einfacher die Daten zu verscherbeln. Mitunter sogar viel gewinnbringender.
immer wieder Beweise dafür liefert, das sie sich einen Dreck um Sicherheit schert.
Kann ich nicht 100% unterstützen.
Ja, ist ja schon gut, gönn' mir doch mein MS-Bashing, ich mach es ja nicht oft und auch nur wo gültig.
Vergleiche mal die Häufigkeit von sicherheitskritischen Fehlern zwischen Windows 2000 und Windows 2003. (Ich möchte dieses Thema jetzt aber nicht wieder aufkochen)
Nien, mußt Du auch nicht, aber einen kleine kann ich ir hier nicht verkneifen, auch weil es wichtig ist: die Anzahl der _bekannten_ Sicherheitslücken ist nicht relevant, noch weniger die Anzahl der _bekanntgegebenen_! Fast alles von MS ist ClosedSource, da _kann_ man nicht reingucken! Somit ist die Anzahl der Sichheitslücken unbekannt. Das ist ein prinzipielles Problem, da beißt die Maus keinen Faden ab.
Das macht aber alles rein gar nix, wenn man bei der Absicherung genau davon ausgeht. Ist sogar erheblich billiger, als sich mit der Windowsabsicherung rumzuschlagen. Das Windows EAL4 erreichen kann ist nur ein rein theoretischer Wert, da mußt Du erstmal jemanden finden, der das auch einstellen kann. Und ob das Dingen nachher benutzbar ist, ist noch eine ganz andere Frage. Am Anfang hatte Unix ganz genau die gleichen Probleme. Aber wie war das doch gleich: Geschichte wiederholt sich immer? ;-)MS SQL Server auf einem Unix, das wäre mal ne interessante Sache ... kann mir auch ungefähr vorstellen wieso. :-)
Ja, MySQL fischt im gleichem Bereich wie MS-SQL und nach der Ankündigung von MySQL letzthin ... ;-)
Na denn, schönen Samstag noch :-)
Wurd' ja auch so langsam Zeit, das man sich wieder mit dem Laptop in den Garten setzen kann. Ich befürchte, ich bekomme schon den ersten Sonnenbrand dieses Jahr ;-)
so short
Christoph Zurnieden
-
-
-
-
-
Mahlzeit,
a) Ich halte es aus Sicherheitsgründen für ungeeignet eine Datenbank public auf einem Webserver (provider gehostet) zu betreiben. Wenn, dann sollte die Datenbank hinter einer Firewall stehen so dass sie nur von den Webservern des Providers selbst bzw. lokal auf dem Server selbst läuft.
b) ich halte es für noch viel riskanter den Datentransfer zwischen Website und Datenbank quer durch das Internet verlaufen zu lassen. Das impliziert genauso, dass deine DB in deinem lokalen Intranet ins Internet _veröffentlicht_ werden muss. Es gibt sicherlich mittel und Wege den Datenverkehr zwischen Webserver und DB Server zu sichern (VPN, SSL) aber dennoch (meines Erachtens nach) reicht dies für Geschäftsdaten nicht als Sicherung aus.
Du solltest dir einen Provider/Hoster suchen, der dedizierte Server hosten kann und außerdem Expertise im Umgang mit MS Server Produkten hat. Du kannst dann einen eigenen Server (mit soviel Plattenkapazität und Ram und CPUs) betreiben lassen (lies: du stellst HW und SW Lizenzen) oder du lässt dir vom Provider ein Angebot mit HW/SW Leasing inklusive machen. Wenn du das sowieso für eine Firma machst, dann kostet es das was es kostet, du kannst dir ja mehrere Angebote einholen. Solche Kosten sollten aber von vornherein bei einem Projekt eingeplant werden (mir scheint, dass da bei euch was versäumt wurde).
Mit dem Provider wird dann ein SLA (Service Level Agreement) gemacht, welche Aufgaben/Gewährleitungen hinsichtlich des Serverbetriebs und der Verfügbarkeit vom Provider übernommen werden. Dort solltest du (mind) darauf achten:
- Sicherung eines annähernd ausfalllosen Produktivbetriebs (RAID, hot/cold standby, Netzwerk backbone)
- Desaster Management (Sicherung der Daten auf Backupsystemen wie Bänder, SAN/NAS ... für den Fall das der ganze Server mal explodiert, denn dann hilft auch kein RAID)
- Konfigurations/Patch/Sicherheitsmanagement ... wie und wann werden sicherheitsrelevante Patches eingespielt, wie sind die Auswirkungen auf deine Appliaktion.
Bevor du wild ins Angebote einholen gehst, solltest du (evt. mit deinen Kollegen) für euch selbst erstmal definieren, welches Verfügbarkeitslevel ihr braucht (24/7, 24/5 ...)
Dazu muss man _noch_ kein DB Experte sein. Das kommt erst später in Sachen Konfiguration des Servers und auch dafür gibt es Spezialisten (wie z.b. mich *grins*)
Ich hoffe, diese Ausführungen haben dir geholfen und bringen dich auf den richtigen Weg.
Ciao, Frank
-
Hello,
aus den Antworten habe ich entnommen, dass selbst die guten Denker verschiedene Dinge nicht auseinanderhalten können:
- Zugriffssicherheit Netzwerkschicht (kein unauthorisierter Zugriff auf die Datenbasis möglich)
- Übertragungssicherheit (kein Missbrauch auf dem Übertragungsweg oder dem simulierten Ü. möglich)
- Gewahrsamsbruch extern (Der Hoster oder einer seiner Mitarbeiter ist korrupt)
- Gewahrsamsbruch intern (einer der eigenen Mitarbeiter ist korrupt)
- Kopiersicherheit einfach (kein Grabbing über konzeptionelle Lücken möglich)
- Kopiersicherheit komplex (kein Grabbing über Implemantationsfehler möglich)
- Detailsicherheit (kein unbeachtetes Sammeln über legale 'Einzelzugriffe'
authorisierter User möglich) - ...
Meistens haben nicht die Scripte, sondern die Konzepte die Lücken. Ich habe hier bei ca. 92% der von mir beratenen Kunden erhebliche Lücken entdeckt und meistens auch beheben können, jedenfalls, wenn kein asp im Einsatz war. Da musst ich meistens passen wegen Ursachen in der Tiefe der Werkzeuge. Die kann und darf ich aber nicht verändern. Mein Fazit: jeder der ASP-Tools verwendet kann seine Daten gleich per Spam an die Branche versenden.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi Tom,
dass selbst die guten Denker verschiedene Dinge nicht auseinanderhalten können
Unfug (ich denke, ich kann da auch für Christoph sprechen), aber danke, dass du das nochmal so haargenau ausklamüsert hast. Hättest dir dafür fast eine positive Bewertung verdient, wenn der erste Satz nicht gewesen wär.
Meistens haben nicht die Scripte, sondern die Konzepte die Lücken.
Was damit ja übereinstimmend festgestellt wurde und das Konzept vom OP besonders.
Schönen Sonntag noch,
Frank-
Hello,
Hättest dir dafür fast eine positive Bewertung verdient, wenn der erste Satz nicht gewesen wär.
Nun sei mal nicht noch kleinlicher als ich *gg*
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
Liebe Experten,
danke für Eure zahlreichen Reaktionen. Es hat sich ja eine richtige Expertenrunde gebildet. Aber genau damit hab ich leider ein Problem, ich bin, wie gesagt, ein db-Laie. So habe ich aus euren Reaktionen rausgehört, dass es gefährlich ist, die db auf einem webhoster zu betreiben. Andererseits ist es auch unsicher, die daten zwischen webhoster und eigenem db-server zu schicken.
könnt ihr mir bitte noch einmal in einfachen worten erklären, wo die vor-und nachteile liegen? (ganz einig wart ihr euch ja auch nicht...)
mir geht es im übrigen weniger um den datenklau als vielmehr darum, dass die db vor misbrauch geschützt ist. (es geht um ein historisches archiv).
ist ein ordentlich konfigurierter webhoster nicht sicher genug (immerhin betreiben doch auch zahlreiche firmen dort ihre dbs, oder?)
wie siht es eigentlich auf den komerziellen hostern (strato, etc. mit dem platz für die db aus? kann ich etwa den angegebenen festplattenplatz auch zum großteil für meine db nutzen oder gibt es da in der regel andere bestimmungen?)
ich will euch mit meinen anfängerfragen aber nicht langweilen. vielleicht habt ihr ja auch einen link, wo solche sachen erklärt sind?
danke!
paul
-
Hi,
könnt ihr mir bitte noch einmal in einfachen worten erklären, wo die vor-und nachteile liegen? (ganz einig wart ihr euch ja auch nicht...)
Na, so im Prinzip waren wir uns schon einig ;-)
_Alles_ in einfachen Worten hier rein zu quetschen ist schlecht möglich. Mit einigen Details zu Deinem Vorhaben kann man es aber machen.mir geht es im übrigen weniger um den datenklau als vielmehr darum, dass die db vor misbrauch geschützt ist. (es geht um ein historisches archiv).
Aha, das ist doch schonmal etwas, an das man sich anhängen kann. Wenn Datenklau egal ist, also jeder die Daten sehen darf, dann kannst Du sicherheitstechnisch schonmal die DB getrost anderen Leuten zur Pflege übertragen. Nur solltest Du Dich dann alleine schon aus Kostengründen von einer Lösung mit Microssoftprodukten absehen (MySQL bekommst Du ja billig, fast schon hinterhergeschmissen). Allerdings kann so eine Portierung natürlich auch wieder ziemlich teuer werden, wenn die DB recht komplex ist. Da die Daten nicht geheim sind und Du DB-Laie könntest Du ja mal zwecks Beurteilung der Komplexität ein kleines Beispiel bringen.
BTW: Was bedeutet "Mißbrauch" genau? Oder mal andersrum:
Soll jemand etwas eintragen/verändern können oder wird die DB ausschließlich(!) gelesen?ist ein ordentlich konfigurierter webhoster nicht sicher genug (immerhin betreiben doch auch zahlreiche firmen dort ihre dbs, oder?)
Woher weißt Du, das er ordentlich konfiguriert ist? ;-)
Aber da Datenklau ja kein Thema ist, entfällt so einiges an Problemen.wie siht es eigentlich auf den komerziellen hostern (strato, etc. mit dem platz für die db aus? kann ich etwa den angegebenen festplattenplatz auch zum großteil für meine db nutzen oder gibt es da in der regel andere bestimmungen?)
Da gibt es meist andere Bestimmungen, die jeweiligen Verträge sind vor Gebrauch also sorgfältig auf Fallen zu prüfen.
Ich würde aber von solchen Riesenbetrieben wie Stato et al absehen und mir eine kelienren Betrieb suchen, der nach Möglichkeit auch noch in der eigenen Region beheimatet ist. Das kostet zwar ein paar Euro mehr, aber soviel ist das auch wieder nicht und es lohnt sich wirklich.ich will euch mit meinen anfängerfragen aber nicht langweilen.
Deine Fragen mögen zwar von einem Anfänger gestellt worden sein, aber Anfängerfragen sind das nicht unbedingt.
vielleicht habt ihr ja auch einen link, wo solche sachen erklärt sind?
Wie, Du willst noch andere Meinungen einholen? Sind wir Dir nicht gut genug? ;-)
so short
Christoph Zurnieden
-
hallo,
Aha, das ist doch schonmal etwas, an das man sich anhängen kann. Wenn Datenklau egal ist, also jeder die Daten sehen darf, dann kannst Du sicherheitstechnisch schonmal die DB getrost anderen Leuten zur Pflege übertragen. Nur solltest Du Dich dann alleine schon aus Kostengründen von einer Lösung mit Microssoftprodukten absehen (MySQL bekommst Du ja billig, fast schon hinterhergeschmissen). Allerdings kann so eine Portierung natürlich auch wieder ziemlich teuer werden, wenn die DB recht komplex ist. Da die Daten nicht geheim sind und Du DB-Laie könntest Du ja mal zwecks Beurteilung der Komplexität ein kleines Beispiel bringen.
ok, ich glaube, ich muss das präzisieren:
1. die daten sind komerziell nicht interessant, d.h. ein webhoster kann sie nicht verkaufen.
2. folgendes sollte aber gesichert sein: in die db soll auch geschrieben/gelöscht werden können (nicht von jedem, zugang zu best. php-seiten über passwortschutz)die absicherung über lesen/schreiben müsste ich doch über unterschiedl. benutzerrechte in der datenbank hinbekommen, oder?
zur portierung nach mySQL: die db besteht aus ca. 30 tabellen, jeweils zw. 3 und 20 spalten, in manchen tabellen gibt es einige tausend einträge. (nur text, keine binaries)
ausserdem gibt es zwischen den tabellen ca. 100 beziehungen.
lässt sich so etwas in mySQL umwandeln?
mfg
Paul
-
Hi,
ok, ich glaube, ich muss das präzisieren:
Ja, das war der Sinn hinter meinen Fragen ;-)
- die daten sind komerziell nicht interessant, d.h. ein webhoster kann sie nicht verkaufen.
Du glaust gar nicht, was alles verkaufbar ist! ;-)
Aber ich nehme das mal als Hinweis, das der Schaden dadurch von euerer Seite vernachlässigbar ist. Gut, dann könnt ihr mehr oder minder ruhigen Gewissens alles beim Hoster lagern.- folgendes sollte aber gesichert sein: in die db soll auch geschrieben/gelöscht werden können (nicht von jedem, zugang zu best. php-seiten über passwortschutz)
die absicherung über lesen/schreiben müsste ich doch über unterschiedl. benutzerrechte in der datenbank hinbekommen, oder?
Wenn das über PHP läuft gibt es eh nur einen Benutzer von außen: PHP. Die Schreibrechte müßtest Du dann also via PHP verwalten. Das ist zwar ein recht komplexes Problem, aber dafür gibt es genügend vorgefertigte Lösungen. Vielleicht reicht da sogar htaccess, wenn eine verschüsselte Verbindung besteht (SSL).
lässt sich so etwas in mySQL umwandeln?
Kann man mit den paar Angaben nicht festlegen. Aber ist meine Schuld, hätte ich dabei sagen sollen: Schwierigkeiten bereiten nicht die Tabellen und Beziehungen, sondern alle Spezialfunktionen, die _ausschließlich_ in MS-SQL vorkommen aber nicht in MySQL. Wenn davon viele verwendet wurden, die erst mühsam in PHP o.ä. nachgebaut werden müßten wird das evt teuerer als mit MySQL gespart werden kann. Ich weiß ja nicht, was euer Budget so hergibt, aber ich würde mich mal bei einem DB-Spezialisten erkundigen, wie hoch da der Aufwand wäre.
Ah, noch was: ich hatte mal einen Fall, da war es am Ende am billigsten einen Mann einzustellen, der per Telephon und Email eingehende Anfragen beantwortete. Da die Daten nicht geheim sind ist das halt nur noch eine reine Kostenfrage.
so short
Christoph Zurnieden
-
Hallo.
Du glaust gar nicht, was alles verkaufbar ist! ;-)
Das glaube ich wirklich nicht. Was heißt denn dieses Wort? So etwas wie "verkäuflich ausschließlich gegen Bargeld"?
MfG, at-
Hi,
Du glaust gar nicht, was alles verkaufbar ist! ;-)
Das glaube ich wirklich nicht. Was heißt denn dieses Wort? So etwas wie "verkäuflich ausschließlich gegen Bargeld"?
Nein.
so short
Christoph Zurnieden
-
-
Hi,
Damit bin ich nur zum Teil einverstanden. Es gibt durchaus Ausbrecher aus dem Käfig des hochdeutschen Dialektes und auch Neuschöpfungen, die nicht unbedingt allen Sprechern dieses Dialektes gefallen mögen. Die Sitte -- so etwas wie Unsitte kann ich bei lebenden Sprachen nicht guten Gewissens feststellen -- ungewöhnlichen Gebrauchs gewöhnlicher Suffixe ist im deutschem Sprachraum nicht ungewöhnlich. In deisem speziellem Fall ist das Suffix -bar nicht bloßes, die Farbe änderndes Suffix sondern ein vollständiges Wort mit eigenständiger Bedeutung. Wer sich dagegen stellt darf auch die Benutung als Präfix, wie z.B. in "Bargeld" oder "barfuß", nicht gutheißen. Du hast jedoch das Wort "Bargeld" benutzt.
so short
Christoph Zurnieden
-
Hallo.
Du hast jedoch das Wort "Bargeld" benutzt.
Und zwar in genau dem von dir angesprochenen Sinn und Zusammenhang.
MfG, at
-
-
-
-
-
Hi Paul,
bezüglich des parallelen Antwortpostings von Christoph, die Portierung deiner MS SQL DB beurteilen zu lassen und berücksichtigend des Faktes, dass du dich nicht für einen Spezi in Sachen DB hältst und es anscheinend auch keine Spezis für MS SQL bei euch im Haus gibt ... wende dich an meine ausnahmsweise hier angegebene eMail Adresse. Ich arbeite seit ca. 5 Jahren mit MS SQL Server.
Ciao, Frank
P.S: schreib bitte SELFHTML in den Betreff, damit ich deine eMail aus den 300 Spam-Mails pro Tag rausfischen kann.
-
-
-