Hallo Christoph, > Wie sieht die Organisation/Umsetzung beim DB-Einsatz aus? Es geht mir > vorallem um die Erweiterbarkeit nach dem Einf�gen von neuen Spalten. > Am Besten ein Beispiel: > Ich habe div. Tabellen ( klar, sonst machts ja keinen Sinn) > und Views. > Einzelne Views sind wieder von anderen Views abh�ngig. In > asp.net habe > ich eine Klasse, welche alle Zugriffe auf die DB in div. > Funktionen zur > Verf�gung stellt. Diese greiffen dann auf die Views zu. > Wenn jetzt eine neue Spalte hinzu kommt, muss ich in allen > Views, welche > davon betroffen sind, diese Spalte auch reinschreiben und dann auch > wieder die DB-Klasse erg�nzen. Ich finde, dass das sehr > Fehleranf�llig > ist, wenn man nicht alles erg�nzt. > Einfacher w�re, wenn ich anstelle der Spaltenaufz�hlungen immer ein * > mache. Dann m�sste die �nderung nicht �berall durchgef�hrt werden. > > Zumindest fr�her hies, dass man das * wegen der Performanceeinbusse > nicht einsetzen soll. Ist das immer noch so(SQL Server 2000) oder ist > der Unterschied zu minim? > > Wie macht ihr das so?
* w�rde ich vermeiden wo immer es geht. Es ist sauberer und weniger fehleranf�llig, expliziten Code zu schreiben. Um problemlos Ver�nderungen an Datenbanken vornehmen zu k�nnen, sollte man diese immer mit Hilfe von gut dokumentierten SQL-Scripts entwickeln, also CREATE TABLE ... ... ALTER TABLE .. ADD CONSTRAINT ... ... CREATE INDEX ... ... CREATE VIEW ... ... CREATE PROC ... Auf diese Weise l��t sich die Datenbank als Sourcecode behandeln. Es ist leichter, �nderungen vorzunehmen (Suche) und diese zu dokumentieren (im Quellcode, in cvs,...). Geschenkt bekommt man noch die M�glichkeit, die Datenbank leicht auf einen anderen Server zu transferieren oder auf ein anderes System zu migrieren. Aber das ist nur meine pers�nliche Meinung. -- Viele Gr��e, Alex _______________________________________________ Coffeehouse mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/coffeehouse
