[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LAPP statt LAMP?



Moin,

* Markus Schulz wrote (2005-11-22 15:07):
>On Tuesday 22 November 2005 14:38, Thorsten Haude wrote:
>> Moin,
>>
>> * Markus Schulz wrote (2005-11-22 12:18):
>[...]
>> >Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts
>> > zu tun haben in die Datenbank auszulagern und bereinigen damit den
>> > Oberflächen Code.
>>
>> Oha, Oberflächecode? Fehlt da nicht eine Schicht? Im Gegensatz zu
>> Triggern halte ich Stored Procedures tatsächlich für gefährlich, die
>> verführen nämlich dazu, DB und Businesslogik zu vermischen. Das kann
>> man richtig machen und trennen, dann kann man aber auch gleich eine
>> richtige Programmiersprache benutzen.
>
>In jedem zweiten Opensource-Webprojekt Projekt wird es genau so gemacht. 
>Natürlich kann und sollte man vom DB-Code abstrahieren. Das spricht 
>jedoch noch absolut nicht gegen den Einsatz von SP.

Doch, genau das ist das Hauptargument gegen Stored Procedures, solange
man sie nicht einsetzt, um den Zugriff zur DB etwas zu erleichtern.


>Und Trigger empfinde ich als komplizierter zu abstrahieren als SP.

Trigger haben nach außen unsichtbar zu sein.


>Würde deine Bedenken also eher genau umgedreht haben. Mir fällt da
>nämlich keine Mögliche Abstraktion ein wie ich unabhängig vom DBMS in
>einer Abstraktionsebene Trigger implementiere für DBMS die das von
>Haus aus nicht beherrschen.

Da gibt's schon Wege, aber ein fehlendes Feature kann man sicher nicht
in allen Fällen ersetzen. Soll das jetzt heißen, daß ich bei Oracle,
PostgreSQL, Firebird etc. auf alles verzichten soll, was MySQL nicht
unterstützt?

>SP kann man dagegen mit SQL Code umsetzen.

Nur, wenn es eine passende Laufzeitumgebung gibt. MySQL kann SQL, aber
eben keine Stored Procedures.


>> >DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte man
>> > da auch kontern, wer das DBMS wechseln muss hat sich im Vorfeld
>> > nicht genügend Gedanken in Bezug auf Skalierbarkeit etc gemacht.
>>
>> Quatsch. Es kann einfach einem proprietären Hersteller einfallen, in
>> einer neuen Version oder einem Servicepack zu verbieten, Vogelbilder
>> in der Datenbank zu speichern. Dann steht man da mit seiner
>> Vogelbildersammlung und muß eine neue Datenbank suchen. Will sagen:
>> es gibt noch deutlich mehr Gründe, das DBMS zu wechseln als Leistung.
>
>Und trotzdem bleibt der Wechsel eines DBMS nicht ohne Arbeit.

Habe ich dem widersprochen?


>Und mehr wollte ich nicht sagen.

Da steht implizit, daß man nur wechseln muß, wenn man skalieren muß,
wenn also die Leistung nicht ausreicht.


>Zumal dein Beispiel mehr als abstrus ist

Weil es um Vogelbilder geht? Dummerweise kann man im Vorhinein nicht
wissen, auf welche absonderliche Gedanken die Hersteller proprietärer
Software kommen.


Thorsten
-- 
No one ever says, "I can't read that ASCII Email you sent me."

Attachment: pgpWC7bM7DBcv.pgp
Description: PGP signature


Reply to: