> 5: Die Tabllen untereinander Referenzieren um mich um Delete und upadte > funktionalit�t evtl. weniger befassen zu m�ssen im > Programmiercode, Nachteil DB > mit Content sind kaum noch Updatef�hig
Cascaded Updates und Deletes machen nur scheinbar das Leben leichter: Weil Mitarbeiter x nicht mehr zum Unternehmen geh�rt, wird 'er' gel�scht. Und alle seine sch�nen Artikel verschwinden mit ihm. Ob das ein Kunde wirklich will? > 6: Stored Procedures sind gut und schnell aber verlangen ein DB > Zugriff bei Logik�nderungen und man kann ihnen nur begrenzt Paramter �bergeben wie z.b. > f�r Sortierung geht das nicht Es ist allemal leichter und geht viel schneller, eine Stored Proc zu �ndern, statt einen Quelltext. Unsere Stored Procs bringen das Ergebnis in jeder gew�nschten Sortierung, indem ein int-Wert daf�r als Parameter mit�bergeben wird (if @sortierung = 1 BEGIN SELECT ... ORDER BY.. END ELSE IF @sortierung = 2 ...) > 11: bekommt bei Euch jeder Content eine eigene Tabelle oder ist > ein Tabelle als Contenthalter mit Kategrien und Schl�sseln besser Eine Tabelle - alles andere dauert viel zu lange. > 12. Datagrids sind gut und Paging und Sorting geht schnell zu realisieren, > aber was wenn 3 Mill. Artikel kommen Dann hat der Programmierer Mist gebaut. Es gibt bei solchen Mengen immer eine Strukturierung, die man dem Benutzer anbieten kann. Tsch��, Joachim ~~~~~~~~~~~~~~~~~~~~~~~~~~~sponsored by United Planet~~~~~~~~~~~~~~~~~ Kaffeepause im United Planet Communityserver ... http://www.intrexx.com/communityserver _______________________________________________ Coffeehouse mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/coffeehouse
