nicht angemeldet
XML oder mysql?
hallo leute,
hab im moment vor einen teil eines systems weg von mydql hin zu XML zu transfairieren!
hat wer erfahrung? mit was muss ich rechnen?
wird das system langsamer? werden mehr ressourcen benötigt?
jimbob
-
hab im moment vor einen teil eines systems weg von mydql hin zu XML zu transfairieren!
????
mysql ist ein db-system
xml eine auszeichnungssprache
wo liegen die gemeinsamkeiten, welche eine alternative darstellen ???
-
z.B:
kann ich interne nachrichten für eine page in einer DB speichern, oder sie als XML datein ablegen!
da linux auf 4 GB beschränkt ist könnte ich jene nachrichten nicht zentral sondern für jede person extra in einer xml datei speichern, was die 4GB schranke umgeht!so ist des!
jimbob
-
die 4 gb barriere gilt für das filesystem.
dem ist es egal, ob die datei von mysql oder vom filesystem angelegt wurde. mit diesem argument kann man auch zig dbs anlegen.aber was sind das für nachrichten, welche 4 gb verbraten?
ich würde dir raten, mal gründlich über die benötigte datenstruktur nachzudenken.
-
Hallo jimbob,
ich würde dir raten, mal gründlich über die benötigte datenstruktur nachzudenken.
auf diesen Gedanken aufbauend mal zwei Diskusionen von mir zum Thema flat-file statt DB.
http://forum.de.selfhtml.org/archiv/2004/8/86978/#m515897
http://forum.de.selfhtml.org/archiv/2004/8/87724/#m522007(Des weiteren suche ich nach wie vor Gründe zum Einsatz einer DB.)
Gruß aus Berlin!
eddi--
at, wie er leibt und lebt auf ein Posting
> > Nein, ich denke nicht.
gepromptet
> Das empfiehlt sich aber.
:))))-
yo,
(Des weiteren suche ich nach wie vor Gründe zum Einsatz einer DB.)
die diskussion scheint ja ein dauerbrenner zu sein und die fronten verhärtet. meiner meinung kommt man zu den gründen für eine datenbank, wenn man ein wenig in die vergangenheit reist und sich anschaut, in welchen szenario dbms entwickelt wurden. schließlich müssen sie einen vorteil gebenüber flat-files haben, diese gab es nämlich vor dbms.
bevor man dbms entwickelt und benutzt hat, ist man auf sehr grosse probleme gestossen, die sich schnell veränderte geschäftswelt in den daten widerzuspiegeln. es war ein problem, wenn mehere programme auf die gleichen datenbestände zugreifen wollten, die aber jeweils unterschiedliche datenstrukturen benutzen. wurde die datenstruktur für ein neues programm geändert, mussten alle anderen dem angepast werden. die dynamik der geschäftswelt war ein problem für die damalige IT-welt.
dbms systeme wurden hauptsächlich aus diesem grund entwickelt, dynamik, bzw. datenunabhängigkeit. mit anderen worten dbms ermöglichen eine datenhaltung unter sich verändernder umgebung. sprich user, programme, daten-design, menge der daten und inhalte, etc. ändern sich ständig und genau dafür sind dbms mit ihren funktionen entwickelt worden.
wenn du dich also fragst, db oder flat files, so werden flat files bei statischen daten immer schneller sein. sobald deine daten aber dynamisch werden, sie sich im laufe der zeit verändern können, unterschiedliche programme drauf zugreifen, etc. genau dann solltest du ein dbms einsetzten.
Ilja
-
yo,
(Des weiteren suche ich nach wie vor Gründe zum Einsatz einer DB.)
die diskussion scheint ja ein dauerbrenner zu sein und die fronten verhärtet.
Oho. Woran machst Du das fest? (mir ist dabei nur daran gelegen für mich das Bestmögliche für meine täglichen Arbeiten herauszufinden)
meiner meinung kommt man zu den gründen für eine datenbank, wenn man ein wenig in die vergangenheit reist und sich anschaut, in welchen szenario dbms entwickelt wurden. schließlich müssen sie einen vorteil gebenüber flat-files haben, diese gab es nämlich vor dbms.
Darum bitte ich auch, daß mir den jemanden deutlich aufzeigt, da ich ihn noch nicht gefunden habe. Viele Programme bringen selbst keine eigene DB mit (Mailclienten) und haben durchaus Datenmassen im Gigabyte-Bereich zu verwalten.
bevor man dbms entwickelt und benutzt hat, ist man auf sehr grosse probleme gestossen, die sich schnell veränderte geschäftswelt in den daten widerzuspiegeln. es war ein problem, wenn mehere programme auf die gleichen datenbestände zugreifen wollten, die aber jeweils unterschiedliche datenstrukturen benutzen. wurde die datenstruktur für ein neues programm geändert, mussten alle anderen dem angepast werden. die dynamik der geschäftswelt war ein problem für die damalige IT-welt.
dbms systeme wurden hauptsächlich aus diesem grund entwickelt, dynamik, bzw. datenunabhängigkeit. mit anderen worten dbms ermöglichen eine datenhaltung unter sich verändernder umgebung. sprich user, programme, daten-design, menge der daten und inhalte, etc. ändern sich ständig und genau dafür sind dbms mit ihren funktionen entwickelt worden.
wenn du dich also fragst, db oder flat files, so werden flat files bei statischen daten immer schneller sein. sobald deine daten aber dynamisch werden, sie sich im laufe der zeit verändern können, unterschiedliche programme drauf zugreifen, etc. genau dann solltest du ein dbms einsetzten.
Vielen Danke für Deine Ausführungen! Genau vor einem solchen Problem stehe ich in der Tat gerade. Ein Datenbestand X wird über drei verschiedene Schnittstellen in unterschiedlichen Formen/Teilen ausgeliefert und gepflegt, kann jeweils ganz oder in Teilen geändert werden.
Wie fk schon feststellte, halte auch ich das nur für eine Frage der durchdachten Strukturierung...
Gruß aus Berlin!
eddi--
at, wie er leibt und lebt auf ein Posting
> > Nein, ich denke nicht.
gepromptet
> Das empfiehlt sich aber.
:))))-
yo,
Viele Programme bringen selbst keine eigene DB mit (Mailclienten) und haben durchaus Datenmassen im Gigabyte-Bereich zu verwalten.
man sollte sich ein wenig vor augen halten, was ein dbms ist. es ist kein magischer kasten, sondern letztlich ist es nur eine software, wie jedes andere programm auch. aber es hat zwei wesentliche merkmale. es ist wie gesagt speziallisiert auf dynamische Daten aller art und zum anderen greift man niemals direkt auf die daten zu, sondern immer über das dbms programm.
insofern macht dein erwähntes mail programm nichts anderes. man greift auf die mails über ein gemeinsames programm zu. es ist quasi einen datenbank aber eben nur für mails. eine "richtige" datenbank versucht nun im gegensatz dazu daten aller art zu verwalten.
Ein Datenbestand X wird über drei verschiedene Schnittstellen in unterschiedlichen Formen/Teilen ausgeliefert und gepflegt, kann jeweils ganz oder in Teilen geändert werden.
dann spricht einiges dafür, eine datenbank zu benutzen.
Wie fk schon feststellte, halte auch ich das nur für eine Frage der durchdachten Strukturierung...
man sollte sich fragen, ob sich der ganze aufwand lohnt und man nicht eventuell in zu grosses projekt angeht. wenn ich einen brief schreiben will, dann werde ich auch nicht anfangen, erst einmal ein text-programm zu schreiben. insofern würde ich die sache anderes angehen. nicht fragen, ob ich eine datenbank brauche, sondern ob ich eine spezialisierte lösung brauche. die macht nämlich deutlich mehr arbeit und birkt viele risiken. dbms sind im gegensatz dazu schon fertig und viele kluge köpfe haben lange zeit sich gedanken darum gemacht. also warum das rad nochmal erfinden, wenn ich es nicht brauche...
Ilja
-
Hallo,
untenstehend möchte ich Dir meinen Eindruck mal so wiedergeben:
#################Eindruch#####################
Ein Datenbestand X wird über drei verschiedene Schnittstellen in unterschiedlichen Formen/Teilen ausgeliefert und gepflegt, kann jeweils ganz oder in Teilen geändert werden.
dann spricht einiges dafür, eine datenbank zu benutzen.
[...] wenn ich einen brief schreiben will, dann werde ich auch nicht anfangen, erst einmal ein text-programm zu schreiben. insofern würde ich die sache anderes angehen.
##############################################
Mehr konkretes ist bis jetzt bei kaum einer Diskussion herrausgekommen...
Im vorherigen Beitrag schriebst Du mir "und die fronten verhärtet". Ich bitte Dich jetzt nicht im Frotenkrieg ;) aktiv in den Schützengraben zu springen sondern mir nur konkret zu erklären, wo für mich und mein folgendes Beispiel die Vorzüge einer DB sind:
- O-Shop -
Berechtigungsstruktur:
Principal - Boss
|
|-ein Vertriebssegment
| |
|-Bereichsleitung | | | |-ein Bereichs MA | | |-noch ein Berichs MA
|
`-noch ein Vertriebssegmentusw.
Artikelstruktur:
Objekt
|
|-Attribute frei wählbar
| |
| |-AT 1
| |
|-AT 2 |-Preis
|
|-Ankauf 1995
|
|-Ankauf 2000
|
`-Ankauf 2004
usw.Tägliches Arbeiten:
- Principal kramt täglich drinn rum
- Bereichschefs kramen täglich drinn rum
mit minderm Privileg- MAs kramen täglich drinn rum (fast
rechtelos)- O-Shop-Kunden kramen drinn rum mit
(bekommen ca. 1/4 an Datenbestand eines
Artikels ausgeliefert)Es sind also sogar fünf Schnittstellen mit der Kasse. Ich bin, wie Du Dir sicher vorstellen kannst, wirklich für jede weiterbringende Diskussion jenseits von der wagen Aussage "dann spricht einiges dafür", die nur in dem Falle, wenn eine Festplatte abk...t Schäden verursacht, dankbar.
Linux sei vorteilhafterweise als mögliches OS gegeben.
Gruß aus Berlin!
eddi--
at, wie er leibt und lebt auf ein Posting
> > Nein, ich denke nicht.
gepromptet
> Das empfiehlt sich aber.
:))))-
yo,
Im vorherigen Beitrag schriebst Du mir "und die fronten verhärtet". Ich bitte Dich jetzt nicht im Frotenkrieg ;) aktiv in den Schützengraben zu springen sondern mir nur konkret zu erklären, wo für mich und mein folgendes Beispiel die Vorzüge einer DB sind:
nun, die vorteile sind schon genannt worden. ein dbms verwaltet eine dynamische umgebung. da ich deine umgebung ja gar nicht kenne, musst du für dich sehen, was alles bei dir dynamisch ist und werden kann. aber ich kann ja mal versuchen, ein wenig davon aufzugreifen.
das erste was mir auffällt sind mehrere benutzer der daten, die auch unterschiedliche rechte haben, was sie mit den daten anstellen können. würdest du kein dbms benutzen, müsstest du quasi eine benutzerverwaltung selbst erstellen, sprich gruppen einrichten, den gruppen rechte geben, benutzer bestimmten gruppen zuteilen, anmeldevorgänge, etc.
was den online-shop betrifft, so fallen dabei viele daten von unterschiedlichen objekte an, z.b kunden, artikel, lieferungen, etc. in diesen daten steckt wohl die meiste dynamik, neue artikel kommen hinzu, alte werde geändert oder gelöscht, die suche nach bestimmten artikeln muss optimiert werden, die abhängigkeit der daten muss berücksichtig werden, die beziehungen zueinander und vieles mehr. schließlich soll ja nur kunde x auch nur die bestellungen sehen, die er gemacht hat.
dann kommt noch hinzu, dass vielleicht mehrere programme auf die daten zugreifen wollen, zum beispiel auf die kundendatei. ohne dbms würde sie alle die gleiche datenstruktur vorraussetzen. ändert sich die einmal, müssten auch wieder alle programme dem angepasst werden.
die sicherung (backup) könnten sich als problematisch erweisen, da ein online shop in aller regel ein 24/7 system ist. würde hier immer eine vollsicherung erfolgen, würde das eventuell den laufenden betrieb zu sehr beeinflußen, sprich man braucht so etwas wie inkrementelle backups. das sperrverhalten der daten ist ein weiteres thema, das behandelt werden muss. macht ja keinen sinn, wenn ein mitarbeiter gerade mal einen artikel ändert und somit der zugriff aller artikel in dem zeitraum nicht mehr möglich ist....
ohne lange um den heißen brei herumreden zu wollen, ich würde bei einem online-shop nicht auf die idee kommen, es ohne dbms zu erstellen. das wort online-shop alleine birkt nämlich eine menge an dynamische daten.
Ilja
-
-
-
-
-
-
-
-
-
hallo jimbob,
sorry fuer meine spaete reaktion, war unterwegs. ich
programmiere auch gerade etwas mit php(oop) mit dem ich
daten als xml-dateien ablege. vielleicht koennen wir
kooperieren. schreibe mir mal eine mail.
ich finde es unsinnig objekt-hierarchische daten wie
sie zum beispiel in einem forum-systen, wcms, cms,
shop, etc. auftauchen in die relational verknuepften
tabellen einer datenbank abzulegen. gruss vom bodensee,michael
hallo leute,
hab im moment vor einen teil eines systems weg von mydql hin zu XML zu transfairieren!
hat wer erfahrung? mit was muss ich rechnen?
wird das system langsamer? werden mehr ressourcen benötigt?jimbob
--
ss:) zu:) ls:& fo:) de:> va:) ch:? n4:& rl:? br:< js:| ie:% fl:{ mo:|