[php] datenbank.

[Hartmut Holzgraefe]

Jens Benecke wrote:
> > auf Sun Enterprise1000 mit 64 CPUs läuft, während M$ sich mittlerweile
> > auf Gedei und Verderb an Intel gekettet hat, und zu dieser Zeit bei Intel
> > über 4 CPUs nicht viel lief
> 
> was natürlich auch jetzt - vom Preis her - immer noch ein riesiger Nachteil
> ist, wenn es um reine "Pumpleistung" (also I/O) geht.
ja, die IO-Bandbreiten in einer großen Sun und erst recht in den großen
/390ern mit PCI und co. erreiche zu wollen ist :(

> > welche Version ist den das? oder sind das die Idealvorstellungen laut
> > Prospekt?  die 8.0.5 tut auch in normalen Dimensionen, d.h. 128MB Ram,
> > 1GB im Filesystem
> 
> Sagen wir so: Das waren m.E. die "empfohlene Umgebung" für die erste
> Version, die für Linux verfügbar war. Natürlich kannst Du die auch auf
> einem P60 mit 16MB installieren, nur Spaß wirst Du damit nicht haben...
> =;)o
mit den von mir genannten Werten war der Spassfaktor schon groß genug,
und
dabei liefen auch noch Entwicklungsumgebung, X und ein Apache mit Java
Servletengine mit ... :)

> Wahrscheinlich hat Oracle das gesagt, damit Leute nicht im Zuge des ganzen
> Linux-Hypes davon ausgehen, daß sie jetzt ihre Ultrasparcs einmotten
> können - die "typischen" Oracle-Installationen fangen halt bei
> zweistelligen GB-Größen an.
die Installationsempfehlungen für Adabas waren ähnlich hoch gegriffen:
eine Platte für System und Programme, eine für Transaction Log,
eine für Recovery-Log, und zwei Datenplatten, besser noch ein Daten-Raid

> äh, ref.Integrität kann MySQL, rät aber ganz stramm davon ab , da
> das meist nur zu überflüssigen Beschränkungen führt, und man die meist
> besser in der Applikation außerhalb der DB prüft.
die entsprecheden SQL-Schlüsselworte 'kann' es (FOREIGN KEY ... und 
ON DELETE ...), aber das sind reine Dummys um Create-Statements aus 
anderen Datenbanken interpretieren zu können, Funktionalität steckt
da kein Stück hinter :(

> > INTERSECT oder UNION (mußte so etwas heute nachbilden, macht warlich
> > keinen Spaß sowas) wenn nichts aus der genannten Liste gebraucht wird,
> > dann ist MySql ein wunderbares, zuverlässiges Arbeitstier
>
> hm, ich meinte, sowas schon mal gesehen zu haben ...
vermutlich im TODO Kapitel der Doku, da wird's erwähnt ... :)


> Das ist richtig, das was mich bei Adabas am meisten anekelt, ist diese
> fürchterliche "WebDB" (proprietärer HTML-Preparser). 
das hab ich mir nie angesehen :) 
meine Adabas-Projekte hab ich immer mit C und Embedded SQL gebaut
das Einzige was da stört ist das der Precompiler keine #file
und #line Preprozessorstatements erzeugt und Fehlermeldungen des
C-Compilers sich dann nicht auf die Quelldatei sondern auf das 
Zwischenergenis beziehen ...

> Da lob ich mir doch PHP :)
sowieso! frei zitiert: 
those who do not know PHP have to reinvent it, badly ;)

so, mehr fällt mir nicht mehr ein, und selbst wenn 
gehörts wohl nich mehr hierher