SQLS + .Net im "Regalsoftware" Szenario - allgemeine Fragen

28/04/2009 - 15:45 von Olaf Rabbachin | Report spam
Huhu!

Ich bastle gerade an einer Anwendung (VB.Net mit SQL 2005/2008), die bei
diversen Kunden laufen wird. Diese Anwendung ist "Regalsoftware", sprich,
ich kenne die Umgebung des Kunden nicht unbedingt.

Da stellt sich mir nun ein paar grundlegende Fragen, das allgemeine
Aufziehen des Szenario betreffend:

1. SQLS Benutzerkonten / SIDs
Die Anwendung wird nur zwei SQLS-Benutzer/Konten aufweisen - eines, das
Zugriff auf ein paar Basisinfos hat (Konnektivitàts-Check, Zugriff auf
die Benutzertabelle) und eines, das die Anwendung regulàr verwendet
("dbo-Zugriff"). Das Hauptkonto ist nur der Anwendung bekannt.
Ich müsste in der DB also zwei Konten erzeugen. Wenn ich per Setup
installiere, sind da Probleme bei den SIDs zu erwarten? Bislang habe ich
das, auf SQLS bezogen, immer per Backup gemacht und anschließendem
Neuerzeugen der Benutzer. Waren halt immer DBs, die für einen Kunden
installiert wurden.

2. Der Kunde soll möglichst per Ausführen des Setups in der Lage sein, die
Anwendung inkl. SQLS und DB zu installieren, also ohne Support. Fragt sich,
ob ich im Rahmen des Setups nicht nur den SQLS (Express) installieren kann,
sondern dann auch noch die DB aufspielen kann? Falls das jemand schon mal
gemacht hat, wàre ich für entspr. Hinweise (Links, Literatur, etc.)
dankbar.

3. Wie kann ich eigentlich verhindern, dass der Endbenutzer/Kunde Zugriff
auf die SQLS-DB erhàlt? Kann man dem <sa> alle Rechte auf eine einzelne DB
entziehen ..?

4. Ich bekomme von den Kunden schon einmal deren Datenbank. Ziel wàre, dass
ich eine solche DB (.bak), hier ohne großen Akt per Restore-batch wieder
aufspielen kann (wieder das SID Problem). Gibt's da Kniffe, bzw. eine
Möglichkeit, die SIDs definierbar/einheitlich zu machen, wenn Konten
erzeugt werden? Außerdem stellt sich natürlich die Frage, wie ich
verhindere, dass der Benutzer per Backup (wird die Anwendung erzeugen
können) und Restore wiederum Zugriff auf die DB bekommt. Würde ungern alle
Objekte in der DB verschlüsseln müssen (und Diagramme entfernen, etc.) ...

5. Das Setup müsste in zwei Teile aufgeteilt werden - einmal der SQLS/DB
und einmal die Anwendung. Wàhrend SQLS und DB einmalig von einem Admin
(oder vom Firmeneigner) installiert werden, ist das bei der Anwendung
insofern anders, als dass diese von den Anwendern selbst installierbar sein
soll. Sprich, die Information über den Namen bzw. die IP des SQLS sowie den
Namen der DB sollten den Benutzern bzw. dem von ihnen ausgeführten Setup
ohne deren Dazutun bekannt gemacht werden. In einem anderen Szenario habe
ich das so gelöst, dass das "Basis-Setup" einmalig ausgeführt wird, dies
beinhaltet die DB-Installation und darüber hinaus das Setup der Anwendung,
das wiederum einfach auf einem öffentlichen Share abgelegt wird. Hier legt
das DB-Setup auch eine Textdatei ab, die die Adresse des SQLS sowie den
Datenbanknamen beinhaltet. Die Benutzer installieren dann per Klick auf
einen Link, den sie per Mail erhalten.
Eine andere Möglichkeit wàre, die per DB-Setup erzeugte Textdatei zusammen
mit dem Anwendungs-Setup an die Benutzer weiterzureichen. Dabei scheidet
dann aber ein CD-Szenario auch wieder aus.
Vielleicht hat da jemand etwas Intelligenteres oder gar den Stein der
Weisen gefunden ..? :-)

Gruß,
Olaf

F'up 2: microsoft.public.de.german.entwickler.dotnet.datenbank
 

Lesen sie die antworten

#1 Günter Prossliner
28/04/2009 - 16:49 | Warnen spam
Hallo Olaf!

1. SQLS Benutzerkonten / SIDs
Die Anwendung wird nur zwei SQLS-Benutzer/Konten aufweisen - eines,
das Zugriff auf ein paar Basisinfos hat (Konnektivitàts-Check,
Zugriff auf
die Benutzertabelle) und eines, das die Anwendung regulàr verwendet
("dbo-Zugriff"). Das Hauptkonto ist nur der Anwendung bekannt.



Bekannt ist es in diesem Sinn dem System. Das Kennwort kann nur der
Anwendung bekannt sein, wobei Du dann automatisch das Problem hast das
Kennwort sicher zu verwahren. Aber dazu spàter.

Ich müsste in der DB also zwei Konten erzeugen. Wenn ich per Setup
installiere, sind da Probleme bei den SIDs zu erwarten?



Du beziehst Dich in Deinem Posting oft auf die SID. Diese spielt nur mit
Windows-Authentifizierung eine Rolle. Der Distributionsprozess ist um
einiges einfacher wenn Du auf SQL-Server Authentifizierung aufbaust.

Es geht mit Windows-Authentifzierung auch. Allerdings sollte die Anwendung
dann als Service (also ein BL-Layer mit z.b. WCF Kommunikation zum Client)
laufen welche unter diesem Windows-User làuft. Ansonsten würdest Du für
jeden (interaktiven) Anwender einen SQL-Benutzer anrichten müssen.

Die Möglichkeit eine Gruppe hàttest Du ggf. auch noch wobei das dann das
Active Directory des Kunden ebenfalls noch in das Setup mit einbeziehen
muss. Wobei wer sagt, dass der Kunde überhaupt ein AD hat? Also, alles recht
komplex. Ausserdem fragt sich der "normale" Beutzer bzw. der "PC-Betreuer"
in KMUs sicherlich was er im Setup nun als "Anwendungsbenutzer" eingeben
muss, was er vorher im AD anlegen muss, ist sicherlich eine
Hemmschwelle für den vermuteten Kundenkreis.

Bislang habe
ich das, auf SQLS bezogen, immer per Backup gemacht und anschließendem
Neuerzeugen der Benutzer.



Backup geht prinzipiell. Allerdings nur für eine Erstinstallation. Du willst
Du ja die Daten des Kunden nach einem Update in seiner DB erhalten, oder ;-)

Der einzig sinnvolle Weg eine Update-Installation auszuführen ist die
Verwendung von SQL-Scripts.

2. Der Kunde soll möglichst per Ausführen des Setups in der Lage
sein, die Anwendung inkl. SQLS und DB zu installieren, also ohne
Support. Fragt sich, ob ich im Rahmen des Setups nicht nur den SQLS
(Express) installieren kann, sondern dann auch noch die DB aufspielen
kann? Falls das jemand schon mal gemacht hat, wàre ich für entspr.
Hinweise (Links, Literatur, etc.) dankbar.



Ja. Eben mittels SQL-Scripts. Mittels T-SQL kann man *alles* machen (ausser
den Diest starten), was auch von der Oberflàche im SQL-Management Studio
möglich ist, welches im Endeffekt auch nur SQL-Scripts generiert (siehe
Button "Script" in (fast) allen Management-Studio Dialogen).

Diese SQL-Statements kannst Du über ADO.Net Commands absetzen. Zu beachten
ist dabei, dass "GO" kein T-SQL Befehl ist, sondern eine Anweisung für den
Query-Processor den aktuellen Befehlsstapel abzusenden. Du musst also bei
einem "GO" den Command ausführen und dann einen neuen erstellen (bzw. den
CommandText leeren).

Ich habe für diesen Zweck eine Komponente geschrieben, in welchen die
einzelnen Update-Scripts nach Modul gruppiert als Embedded Resource in den
Assemblies liegen. Wenn also ein Modul names "Ordering" existiert, gibt es
einen Folder in dem Projekt in welchen z.b. die Dateien "1.0.sql", "1.4.sql"
und "2.3.sql" liegen. In einer speziellen Tabelle speichere ich mir welche
Version des Moduls auf der DB installiert wurde. Wenn ein Kunde z.b. die
Version 1.0 installiert hat wird beim Update das Script 1.4. und 2.3
ausgeführt. Wenn ein anderer Kunde die 1.4er Version installiert hat wird
nur das 2.3.sql Script ausgeführt. Bei einer Neuinstallation werden alle
Scripts ausgeführt (wobei ich in meiner Komponente da auch die Möglichkeit
habe ein "CompleteInstallationScript" für eine Version anzugeben). Wichtig
ist es das ganze Update-Script in einer Transaktion auszuführen welche auch
der Setzen der Version umfasst. Dann kann eigentlich nichts schiefgehen -
bzw. wenn was schiefgeht dann werden *alle* Änderungen vom SQL-Server
gerollbacked.

Somit ist der Aufwand eine DB zu erstellen der folgende: ein "CREATE
DATABASE" Statement absetzen und anschliessen die Komponente aufrufen welche
die Scripts ausführt.

3. Wie kann ich eigentlich verhindern, dass der Endbenutzer/Kunde
Zugriff auf die SQLS-DB erhàlt? Kann man dem <sa> alle Rechte auf
eine einzelne DB entziehen ..?



Im Endeffekt gar nicht. Da Du keine Adminrechte am SQL-Server Rechner
entziehen kannst, kannst Du nicht verhindern dass der Kunde am SQL-Server
selbst zum Admin macht und dann einen User anlegt welcher das kann bzw. das
Kennwort àndert usw. Er könnte aber einfach ein Backup machen und woanders
einspielen bzw. die Datendateien an einem anderen Server attachen,

Es sollte aber auch nicht notwendig sein. Im Endeffekt sind es ja die Daten
des Kunden und nicht Deine (oder lieferst Du einen fixen Datenbestand aus)?

Solche Dinge werden i.d.R. in Lizenzbestimmungen geregelt (dass z.b. kein
Schemamodifikationen erlaubt sind). Wenn es ein Kunde dennoch macht verliert
er Gewàhrleistung und Support.

4. Ich bekomme von den Kunden schon einmal deren Datenbank. Ziel
wàre, dass ich eine solche DB (.bak), hier ohne großen Akt per
Restore-batch wieder aufspielen kann (wieder das SID Problem).



Nein. Du bist Admin auf Deinem SQL-Server. Somit kannst Du auf die DB
zugreifen.

Gibt's
da Kniffe, bzw. eine Möglichkeit, die SIDs definierbar/einheitlich zu
machen, wenn Konten erzeugt werden?



Ausser auf SIDs zu verzichten (in dem man SQL-Server Authentifizierung
verwendet) nicht.

Außerdem stellt sich natürlich
die Frage, wie ich verhindere, dass der Benutzer per Backup (wird die
Anwendung erzeugen können) und Restore wiederum Zugriff auf die DB
bekommt. Würde ungern alle Objekte in der DB verschlüsseln müssen
(und Diagramme entfernen, etc.) ...



Wenn Du die Datenbank scriptest (was für das Setup ohnehin notwendig sein
wird), sind solche Dinge steuerbar und z.b. Diagramme sind gar nicht
drinnen.

5. Das Setup müsste in zwei Teile aufgeteilt werden - einmal der
SQLS/DB und einmal die Anwendung. Wàhrend SQLS und DB einmalig von
einem Admin (oder vom Firmeneigner) installiert werden, ist das bei
der Anwendung insofern anders, als dass diese von den Anwendern
selbst installierbar sein soll. Sprich, die Information über den
Namen bzw. die IP des SQLS sowie den Namen der DB sollten den
Benutzern bzw. dem von ihnen ausgeführten Setup ohne deren Dazutun
bekannt gemacht werden.



IMO ist es dem "normalen" Benuter durchaus zuzumuten dass z.b. der
Netzwerkname des Servers angegeben werden kann. Dinge wie den Namen der DB
würde ich entweder gar nicht konfigurierbar machen, oder selbst ermitteln
(z.b. könnte das Setup eine extented Property auf Serverebene definieren
oder z.b. einfach in allen DBs schauen wo Deine Objekte (z.b. die Tabelle
mit den Versionsnummern) zu finden sind.

In einem anderen Szenario habe ich das so
gelöst, dass das "Basis-Setup" einmalig ausgeführt wird, dies
beinhaltet die DB-Installation und darüber hinaus das Setup der
Anwendung, das wiederum einfach auf einem öffentlichen Share abgelegt
wird.



Dadurch verlagerst Du aber den Aufwand vom Benutzer zum PC-Betreuer. Dieser
muss dann im Setup z.b. ein Share angeben.

Eine IMO gute Kombination wàre es nach dem "Server-Setup" z.b. eine .xml
oder Textdatei mit dem Servernamen zu generieren und den Admin ausgibst,
dass er diese in dem selben Ordner wie das Client-Setup legen kann. Wenn das
Client-Setup diese Datei findet dann verwendet es diese Infos, ansonsten
muss der Client-Setup Benutzer den Servernamen eingeben.

Hier legt das DB-Setup auch eine Textdatei ab, die die Adresse
des SQLS sowie den Datenbanknamen beinhaltet.



Soweit sogut.

Die Benutzer
installieren dann per Klick auf einen Link, den sie per Mail erhalten.



Wer sendet dann das Mail? Woher kennst Du die Benutzer? Was ist wenn sich
jemand "nachtràglich" das Client-Program installieren will? Finde ich so wie
es dasteht keinen so gute Idee.

Eine andere Möglichkeit wàre, die per DB-Setup erzeugte Textdatei
zusammen mit dem Anwendungs-Setup an die Benutzer weiterzureichen.



Das wàre eben die Sache mit der (optionalen) Konfigurationsdatei welche vom
Server-Setup generiert und vom Client-Setup gelesen wird.

Dabei scheidet dann aber ein CD-Szenario auch wieder aus.



Du wirst nichts daran àndern können, dass eine CD ein read-only Medium ist
;-)

Vielleicht hat da jemand etwas Intelligenteres oder gar den Stein der
Weisen gefunden ..? :-)



Einen Stein der Weisen gibt es nicht. Jede Variante hat ihre Nachteile (und
hoffentlich auch Vorteile).

So könntest natürlich mit UDP Broadcasts das Netzwerk nach "Deinen" Servern
durchsuchen. So findest im Endeffekt auch z.b. das Management Studio die
SQL-Server (das kannst Du übrigens auch in C# machen. Stichwort
"NetServerEnum"). Würde ich Dir allerdings nicht empfehlen, da es bei vielen
Netzwerkkonfigurationen nicht funktioniert (Routing, Firewalls).



OK soweit?
mfg GP

Ähnliche fragen