Script-Management

[Pathomorph 1]

Hi zusammen

 

Ich habe eine Datenbank mit zig UDFs. Dieser werden jedoch alle unstrukturiert untereinander angezeigt und so blick ich nicht mehr durch, welche Funktion, wofür ist.

Kann man diese strukturieren? Ich dachte da an eine Ordner-Struktur o.ä.

Mit Schemas kann man die schon gruppieren, reicht aber nicht ganz aus...

 

Gibt es ggf. andere Tools, die solche Skripte vernünftig verwalten?

 

Gruß

[zahni 554]

Hm, Du hast also eine DB mit vielen UDF's ?  Was glaubst Du passiert wenn Du den Namen oder das Schema änderst ?

Du solltest mit dem Entwickler reden, ob er Namen verwenden kann, die man leichter identifizieren kann.

[Pathomorph 1]

Nun.. Ich bin selbst der Entwickler...

Mit ist das schon bewusste, was bei einer Änderung passiert. 

Die Funktionen sind aus verschiedenen Bereichen: Type-Converter, Reports zu bestimmten Themen usw. Nur anhand der Namen die Funktionen zu ordnen finde ich schwierig oder ich bin nicht kreativ genug..

 

Willst du mir also sagen, es gibt nichts in der Richtung? 

 

Thx für die Antwort

[zahni 554]

Dir bleibt beim Design nur die Schemas und sinnvolle Namen. BTW: So viele UDF's finde ich etwas ungewöhnlich. Zumal die bei falscher Verwendung ziemliche Probleme (u.a. Performance) verursachen können. Reports solltest Du in die Report. Services verlagern. Dort, bzw. mit einem passenden Web-Frontend, kannst Du Strukturen bauen wie willst. 

[Pathomorph 1]

Nun ja.. Ich habe eine Datenbank mit 268 Tabellen.

Um Auswertungen machen zu können, brauche ich vorbereitete Daten, die teilweise nur mit Views gehen oder, bei komplexen Daten, mit entsprechenden Funktionen.

Views mag ich nicht, also rein in eine Tabellenwert-Funktion...

So entstehen viele UDF's...

 

Wir haben ca. 300 Kunden, die unterschiedliche Auswertungen brauchen. Bekommen also nur Häppchen davon als Script.

 

Damit ich aber durch alle Funktionen durchblicke, teilweise Basisfunktionen, teilweise kundenspezifische, brauche ich irgendeine Übersicht. Kann auch ein Editor sein oder Document-Management-System oder gar die Festplatte mit Unterordnern...

[zahni 554]

Views sind aber das übliche Vorgehen.

[Pathomorph 1]

Üblich? Mag sein.. Aber nicht zwingend die richtige(re) Entscheidung. 

Der Query-Optimizer macht da keine Unterscheidung und der Execution-Plan ist identisch...

 

Ausserdem habe ich Funktionen, die durchaus komplexer sind. Mit Variablen und mit einer Logik, nicht nur paar Tabellen gejoint und Ausgabefelder angeben...

 

Gruß

[zahni 554]

Die Frage ist halt, ob der SQL-Server UDF's optimieren kann. Wenn man die in externen Code auslagert (wie z.B. bei DB2 mit Java oder C) garantiert nicht. Bei reinen SQL-Functions mag das so sein.

Eine View lässt sich immer optimieren. Wie gesagt: Eine DB mit vielen UDF's habe ich noch nicht gesehen. Java-Programmierer arbeiten eh gern mit Hibernate. Hibernate  hat es wohl nicht so mit UDF's. Die Vergabe von Berechtigungen wird auch schwieriger. Enduser bekommen normalerweise nur Zugriff auf Views.

Wenn die Kundendaten alle in einer DB stehen, kann man die Kunden-Views leicht in Schemas auslagern und u.a. auf Schema-Ebene Berechtigungen (z.B. Createin,Dropin, Alterin) erteilen (zumindest in DB2).

 

Unsere Fachkraft für das Thema bekommt fast Alles mit Views hin:D

 

Möglicherweise würde Deine Lösung bei uns durch die Validierung fallen ;)

[Pathomorph 1]

Unsere "EndUser" wissen nicht mal was SQL ist... Daher ist das Thema Berechtigungen irrelevant... Es gibt nur einen DB-User, der dbowner ist 

Ich bastel auf dem SQL-Server Funktionen oder meinetwegen Views, die ich dann von Excel aus "bediene". Der EndUser wählt in Excel nur die Auswertung, die er haben will und basta.