[.NET/MSDE] Database per gebruiker ipv Client-Server

[Verwijderd]

We hebben een .NET applicatie ontwikkeld die draait met SQL-server of de MSDE versie daarvan. Dit kan uitstekend uitgerolt worden bij bedrijven waarbij de gegevens opgeslagen worden in één database server.

het vraagstuk
Echter voor lesdoeleinden wordt het volgende gewenst:
Per gebruiker een eigen database, waarbij het mogelijk is om je eigen data op te slaan (bijv op memory stick) en deze weer terug te zetten wanneer men wenst.

de oplossing (?)
Een lokale installatie op alle desktops van MSDE (= toch gratis)
Nu zat ik te denken aan een tooltje die via wat onderhuidse scripts de database backupt en vraagt waar je 'em wilt opslaan. Hetzelfde idee om de database terug te zetten.

Omdat ik het een beetje een ranzige oplossing vind en twijfel of ik alle opties overzie vroeg ik me af
wat denken jullie er van, zijn er andere mogelijkheden!??

[whoami]

Dit is ranzig. Je gaat nu, als ik het zo zie, een databank gaan gebruiken als een 'file'.
Waarom niet één databank die centraal op een server staat, en iedereen krijgt een eigen account. De gegevens van persoon A worden aan de account van persoon A gekoppeld , etc....

De manier die jij voorstelt, is gewoon ranzig, en het kan nooit de bedoeling zijn om zo met een DB te werken.
Als je het toch persé zo wilt doen, dan zou ik niet werken met het 'backuppen' van databases, maar met het attachen / detachen.

[pjvandesande]

Je zou kunnen werken met attach en detach, dus het koppelen en ontkoppelen van een database. Een voorbeeld hiervan vind je hier.

Het klinkt een beetje alsof je mssql wilt gaan gebruiken als access. De bedoeling van een Database is data bewaren, iederen user een eigen database lijkt mij niet echt de bedoeling. Goede koppelingen binnen de database zal meer opleveren denk ik.

Wat is precies de reden dat je dit wilt?

offtopic:
whoami

[ Voor 49% gewijzigd door pjvandesande op 21-09-2005 15:02 ]

[Verwijderd]

whoami schreef op woensdag 21 september 2005 @ 14:51:
Dit is ranzig. Je gaat nu, als ik het zo zie, een databank gaan gebruiken als een 'file'.
Waarom niet één databank die centraal op een server staat, en iedereen krijgt een eigen account. De gegevens van persoon A worden aan de account van persoon A gekoppeld , etc....

De manier die jij voorstelt, is gewoon ranzig, en het kan nooit de bedoeling zijn om zo met een DB te werken.
Als je het toch persé zo wilt doen, dan zou ik niet werken met het 'backuppen' van databases, maar met het attachen / detachen.

Op scholen moeten studenten individueel hun eigen gegevens bekijken. De applicatie is al ontwikkeld en bij 'normaal' gebruik wil je nooit afstappen van het client/server idee. Echter om met het pakket te leren werken is het wel zo handig dat iedereen alleen met z'n eigen rommel zit.

Ik ben het dus met je eens dat het ranzig is, jou voorstel hadden we ook bekeken maar is erg kostbaar om dit aan te passen. Echter aan de scholen zullen we in directe zin weinig verdienen (eventueel interessant is de indirecte spin-off).

Database op de persoonlijke drive *Nieuw idee*
Doorgaans krijgen studenten op scholen een eigen drive letter waar ze hun persoonlijke rommel kunnen opslaan. Middels een script zouden we op deze drives een lege database kunnen uitrollen.
Wanneer de connectiestring keihard staat naar: H:\applicatie\applicatie.mdf zou iedereen z'n eigen database krijgen.
Echter het is niet toegestaan om op een andere locatie dan op de locatie van de database server zelf deze bestanden aan te maken...

Naast het attach/detach-dee, moet ik me ook maar eens verdiepen of dit echt niet mogelijk is.

[ Voor 57% gewijzigd door Verwijderd op 21-09-2005 15:31 ]

[Gé Brander]

Je gaat dus uit van decentrale SQL Server's op de werkstations waarbij je op een netwerkschijf de mdf, ndf en ldf files wil opslaan? Dit is niet supported maar kan wel. Zou ik dus niet doen!
Waarom niet een centrale SQL Server met iedereen een eigen database en eigen login? Maak een optie waarbij iedereen een export of dump van zijn database kan maken en deze thuis kan restoren, maar ja, wie heeft er thuis nu allemaal MSDE/SQL Server draaien?

[RobIII]

SQL:

Backup [dbname] to disk = 'F:\somedir\somefile.bak'

En natuurlijk de tegenhanger:

SQL:

Restore [dbname] from disk = 'F:\somedir\somefile.bak'

Niet dat het een mooie oplossing is...

[Annie]

Is het mogelijk om de connectiestring per gebruiker aan te passen? Zo ja, ga dan - zoals al eerder gezegd - voor meerdere databases. Je kan in de connectiestring opgeven welke Initial Catalog je wil gebruiken, of de logins een verschillende default database geven. Iedereen werkt zo met z'n eigen gegevens.
En het is zelfs mogelijk om alles in dezelfde database te gooien en meerdere malen de objecten met verschillende owner aan te maken (natuurlijk alleen mogelijk indien de applicatie niet overal de owner specificeert in de object-verwijzingen). SQL Server zal eerst in het 'schema' van de ingelogde gebruiker zoeken naar een object, en daarna pas in het default 'dbo' schema.

Als in de applicatie hard wordt verwezen naar een database, dan zit er afaik niets anders op dan meerdere instances draaien op een server of met locale installaties werken.

[ Voor 3% gewijzigd door Annie op 21-09-2005 23:00 ]

[Verwijderd]

Erm... dit is niet offensive bedoeld echter meerdere databases is het stomste wat je kan doen, helemaal binnen software engineering waarbij onderhoudbaarheid één van de belangrijkste design issues is. Wanneer je een update hebt binnen de database wat ga je dan doen? Een script bouwen om alle duizenden studenten de database te laten updaten? Er zal vast een situatie komen waarbij je een nieuw veld nodig hebt of iets anders (een ander veld type, etc). Zeker in de software engineering is dit 100% mogelijk omdat er altijd updates plaats zullen vinden. Ik zou absoluut niet kiezen voor meerdere databases. 1 database, 1 onderhoudbaarheids punt is in mijn optiek het beste.

[Rodyman]

Waarom niet als volgt:

Eén centrale SQL Server database (of desnoods msde) die voor iedereen toegankelijk is. Je maakt op die server voor alle gebruikers een database en een user aan. Die user geef je alleen rechten op die ene database.

Zo kan iedereen maar bij 1 database, en kunnen ze hem overal benaderen.

[Verwijderd]

c70070540 schreef op woensdag 21 september 2005 @ 20:20:
Je gaat dus uit van decentrale SQL Server's op de werkstations waarbij je op een netwerkschijf de mdf, ndf en ldf files wil opslaan? Dit is niet supported maar kan wel. Zou ik dus niet doen!

Ik twijfel ook nog of je dit uberhaupt moet willen, echter ik ben er nog niet achter hoe het wel kan. SQLServer vertikt het om op een andere locatie dan lokale harde schijven de database uit te rollen. Ik hoor 't graag als je toch een truukje weet!

Waarom niet een centrale SQL Server met iedereen een eigen database en eigen login? Maak een optie waarbij iedereen een export of dump van zijn database kan maken en deze thuis kan restoren, maar ja, wie heeft er thuis nu allemaal MSDE/SQL Server draaien?

Inderdaad ook een optie. Echter nu moet de administrator bijhouden welke databases nog actief zijn en welke niet.

Annie schreef op woensdag 21 september 2005 @ 23:00:
Is het mogelijk om de connectiestring per gebruiker aan te passen? Zo ja, ga dan - zoals al eerder gezegd - voor meerdere databases. Je kan in de connectiestring opgeven welke Initial Catalog je wil gebruiken, of de logins een verschillende default database geven. Iedereen werkt zo met z'n eigen gegevens.
En het is zelfs mogelijk om alles in dezelfde database te gooien en meerdere malen de objecten met verschillende owner aan te maken (natuurlijk alleen mogelijk indien de applicatie niet overal de owner specificeert in de object-verwijzingen). SQL Server zal eerst in het 'schema' van de ingelogde gebruiker zoeken naar een object, en daarna pas in het default 'dbo' schema.

Als in de applicatie hard wordt verwezen naar een database, dan zit er afaik niets anders op dan meerdere instances draaien op een server of met locale installaties werken.

De connectiestring staat nu hard, maar het zou niet zo'n grote aanpassing zijn om die instelbaar per gebruiker te maken. Toch heeft mijn voorkeur nog de database server en applicatie lokaal te draaien. Bij normaal testgebruik zal de database tussen de 10 en de 100MB zijn. Alle databases op een server zorgt ervoor dat MSDE wellicht geen optie meer is.

Rodyman schreef op woensdag 21 september 2005 @ 23:30:
Waarom niet als volgt:

Eén centrale SQL Server database (of desnoods msde) die voor iedereen toegankelijk is. Je maakt op die server voor alle gebruikers een database en een user aan. Die user geef je alleen rechten op die ene database.

Zo kan iedereen maar bij 1 database, en kunnen ze hem overal benaderen.

Ook intensief in beheer. En ja, je kan natuurlijk scripten maar het klinkt alsof er redelijk wat nazorg aan te pas komt om de beheerders hiermee te helpen.

[ Voor 56% gewijzigd door Verwijderd op 22-09-2005 07:23 ]

[Gé Brander]

Verwijderd schreef op donderdag 22 september 2005 @ 07:16:
[...]

Ik twijfel ook nog of je dit uberhaupt moet willen, echter ik ben er nog niet achter hoe het wel kan. SQLServer vertikt het om op een andere locatie dan lokale harde schijven de database uit te rollen. Ik hoor 't graag als je toch een truukje weet!

Hierbij:

DBCC TRACEON

Network Database Files (1807)
SQL Server will not allow you to create a database or log file on a networked drive by default. If you attempt to do this, you receive error 5105, which states "Device Activation Error." The 1807 trace flag provides a workaround for this restriction, and you can create database files on a mapped drive or UNC path. However, just because you can do something doesn't mean you should. This trace is undocumented for a good reason. It is an incredibly bad idea to place a database file on a network drive. The support for this feature was added to help vendors like Network Appliance (http://www.netapp.com/). Storing data on a network drive opens another potential can of worms, because you must monitor and provide redundancy for that drive. If network connectivity is interrupted, your database goes down.

Niet doen dus...

[Verwijderd]

c70070540 schreef op donderdag 22 september 2005 @ 11:19:....
Niet doen dus...

Ik had het ook net gezien. Dat wordt em dus inderdaad ook niet!

[Verwijderd]

Annie schreef op woensdag 21 september 2005 @ 23:00:
Is het mogelijk om de connectiestring per gebruiker aan te passen? Zo ja, ga dan - zoals al eerder gezegd - voor meerdere databases. Je kan in de connectiestring opgeven welke Initial Catalog je wil gebruiken, of de logins een verschillende default database geven. Iedereen werkt zo met z'n eigen gegevens.
En het is zelfs mogelijk om alles in dezelfde database te gooien en meerdere malen de objecten met verschillende owner aan te maken (natuurlijk alleen mogelijk indien de applicatie niet overal de owner specificeert in de object-verwijzingen). SQL Server zal eerst in het 'schema' van de ingelogde gebruiker zoeken naar een object, en daarna pas in het default 'dbo' schema.

Als in de applicatie hard wordt verwezen naar een database, dan zit er afaik niets anders op dan meerdere instances draaien op een server of met locale installaties werken.

Dit gaat em toch worden! Scholen kunnen SQLServer via SLIM toch goedkoop krijgen. Bedankt allen voor de tips!

[ Voor 6% gewijzigd door Verwijderd op 23-09-2005 08:10 ]

[P_de_B]

Ik snap niet dat iedereen dit zo'n ranzige oplossing vind Ik heb een aantal cursussen gevolgd waarbij hetzelfde principe werd toegepast. Een lokale database waar je naar hartelust op kon oefenen en de labs uit de cursus volgen. Als je dan te maken hebt met meerdere mensen die op de pc de cursus volgen lijkt het me handig een backup te kunnen maken van user 1 en die te kunnen restoren nadat user 2 een gedeelte van de cursus heeft afgelegd.

Ik begrijp tenminste dat het niet voor een productieomgeving is, maar voor trainingen.

[Annie]

Idd, in dit geval is het helemaal niet zo'n slecht idee (niet iedereen vond het idee ranzig ). Of je dan met een centrale server werkt of met lokale instanties is afhankelijk van je infrastructurele mogelijkheden en/of licenties.
Lood om oud ijzer als je het mij vraagt. Wat mij betreft met een lichte voorkeur voor een centrale server, dat is net wat makkelijker in het beheer. Maar die keuze is dus afhankelijk van factoren die alleen de TS kent.

Het uitrollen van changes of het terugzetten van de omgevingen is dan een kwestie van 1x wat beheescripts schrijven (sql, batch) en daarna is alles geregeld met een spreekwoordelijke druk op een knop.