Archief - C# en SQL in een desktop applicatie, hoe een gegenereerd database formaat updaten?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
T

Tyfius

Legacy Member
Ik ga voor de eerste maal in mijn leven een SQL database gebruiken in een C# project en ik heb een aantal vraagjes.

Ik zit met een desktop applicatie, dus mijn oog is momenteel gevallen op de SQLite implementatie van System.Data.SQLite omdat ik meerdere lokale database files wil. Zij bieden ook een LINQ provider aan, allemaal heel interessant maar hier is het waar de documentatie en de goede voorbeelden mij een beetje in de steek laten.

Om een database file aan te maken zijn er twee manier: Ik genereer een via de grafische designer, die op dezelfde manier werkt als een gewone SQL server database. Het probleem hier zit dat ik mijn database file straks in de AppData folder van de gebruiker wil en niet naast mijn executable en die moet natuurlijk bruikbaar zijn voor alle developers die via SVN de source uitchecken. Daar heb ik nog niets op gevonden. Ten tweede weet ik niet exact hoe ik mijn database kan updaten naar een volgende versie bij een update van mijn applicatie. Ik kan die bestaande .db file natuurlijk niet zomaar overschrijven maar alle data moet correct gemigreerd worden en er zou een controle moeten zijn dat een gebruiker bij het starten van de applicatie er op gewezen wordt dat zijn database te nieuw is voor de software.

De tweede manier is om alles manueel te doen. Ik kan exact bepalen waar ik mijn database file wil hebben, ik kan met een soort incrementele counter werken om mijn database formaat te controleren en desnoods te updaten bij het starten van de applicatie. Maar dat wil zeggen dat ik zelf voor alles query's moet gaan schrijven. Voor mij geen probleem, ik ben redelijk vloeiend in SQL, maar niet iedereen is dat. Een tweede probleem is dat je dan nogal snel veel moet aanpassen: de query die de database aanmaakt, het datamodel dat intern wordt gebruikt, alle query's die data manipulatie doen om een tabel in de database,... Als ik dat zou kunnen doen via een paar muis klikken is dat een pak interessanter.

Heeft iemand hier een idee van, ervaring mee, voorbeelden, aanraders voor andere database formaten of een deftige work-flow?
O

Obliv`

Legacy Member
Tyfius zei:
Ik ga voor de eerste maal in mijn leven een SQL database gebruiken in een C# project en ik heb een aantal vraagjes.

Ik zit met een desktop applicatie, dus mijn oog is momenteel gevallen op de SQLite implementatie van System.Data.SQLite omdat ik meerdere lokale database files wil. Zij bieden ook een LINQ provider aan, allemaal heel interessant maar hier is het waar de documentatie en de goede voorbeelden mij een beetje in de steek laten.

Om een database file aan te maken zijn er twee manier: Ik genereer een via de grafische designer, die op dezelfde manier werkt als een gewone SQL server database. Het probleem hier zit dat ik mijn database file straks in de AppData folder van de gebruiker wil en niet naast mijn executable en die moet natuurlijk bruikbaar zijn voor alle developers die via SVN de source uitchecken. Daar heb ik nog niets op gevonden. Ten tweede weet ik niet exact hoe ik mijn database kan updaten naar een volgende versie bij een update van mijn applicatie. Ik kan die bestaande .db file natuurlijk niet zomaar overschrijven maar alle data moet correct gemigreerd worden en er zou een controle moeten zijn dat een gebruiker bij het starten van de applicatie er op gewezen wordt dat zijn database te nieuw is voor de software.

De tweede manier is om alles manueel te doen. Ik kan exact bepalen waar ik mijn database file wil hebben, ik kan met een soort incrementele counter werken om mijn database formaat te controleren en desnoods te updaten bij het starten van de applicatie. Maar dat wil zeggen dat ik zelf voor alles query's moet gaan schrijven. Voor mij geen probleem, ik ben redelijk vloeiend in SQL, maar niet iedereen is dat. Een tweede probleem is dat je dan nogal snel veel moet aanpassen: de query die de database aanmaakt, het datamodel dat intern wordt gebruikt, alle query's die data manipulatie doen om een tabel in de database,... Als ik dat zou kunnen doen via een paar muis klikken is dat een pak interessanter.

Heeft iemand hier een idee van, ervaring mee, voorbeelden, aanraders voor andere database formaten of een deftige work-flow?
Klik om te vergroten...

De tweede manier is in mijn ogen de enige correcte. Dan heb je tenminste over alles volledige controle.

In verband met de database up to date te houden, kan je misschien eens kijken naar migratordotnet - Project Hosting on Google Code . Tijdens het opstarten kan je misschien een script uitvoeren dat migrator start. Migrator checkt automatisch of er database updates moeten worden uitgevoerd.
T

Tyfius

Legacy Member
Ik ben op een ander forum in de richting van Fluent NHibernate gewezen en de eerste testen zijn vrij positief om alles te kunnen doen wat ik wil.

De komende dagen ga ik hier nog een beetje meer mee experimenteren.
M

Moto

Legacy Member
Ik ben op een ander forum in de richting van Fluent NHibernate gewezen en de eerste testen zijn vrij positief om alles te kunnen doen wat ik wil.
Klik om te vergroten...
Als het enkel is om records op te halen/updaten en te deleten (typische crud) zou ik zeggen, niet doen. Ik vraag mij af waarom mensen maar die NHibernate willen gebruiken???

Entity Framework is een optie voor Crud als ge snel snel wat wilt bricoleren en niet teveel data + tables hebt.

Moet het deftig zijn -> Welcome to BLToolkit - Business Logic Toolkit for .NET

anyways
Voor mij geen probleem, ik ben redelijk vloeiend in SQL, maar niet iedereen is dat.
Klik om te vergroten...
iedereen zoals de gebruikers?, allez developers die niet vloeiend zijn in SQL moeten het maar effe opzoeken, of een andere job kiezen :p

Een tweede probleem is dat je dan nogal snel veel moet aanpassen: de query die de database aanmaakt, het datamodel dat intern wordt gebruikt, alle query's die data manipulatie doen om een tabel in de database,...
Klik om te vergroten...
Tja een update-scriptje
+ uw mapping aanpassen als ge een ORM gebruikt
+ al de rest offcourse

Als ik dat zou kunnen doen via een paar muis klikken is dat een pak interessanter.
Klik om te vergroten...
Niet mogelijk, en als er dingen bestaan die dat "verkopen", wil ik het wel horen ze :p
Zie dat eerder als die dingen op TV-shopping kanalen waar ge zaken kunt kopen waar ge zonder moeite/inspanning mee afvalt, never gonna happen :p
T

Tyfius

Legacy Member
Moto zei:
Als het enkel is om records op te halen/updaten en te deleten (typische crud) zou ik zeggen, niet doen. Ik vraag mij af waarom mensen maar die NHibernate willen gebruiken???

Entity Framework is een optie voor Crud als ge snel snel wat wilt bricoleren en niet teveel data + tables hebt.

Moet het deftig zijn -> Welcome to BLToolkit - Business Logic Toolkit for .NET

anyways

iedereen zoals de gebruikers?, allez developers die niet vloeiend zijn in SQL moeten het maar effe opzoeken, of een andere job kiezen :p


Tja een update-scriptje
+ uw mapping aanpassen als ge een ORM gebruikt
+ al de rest offcourse


Niet mogelijk, en als er dingen bestaan die dat "verkopen", wil ik het wel horen ze :p
Zie dat eerder als die dingen op TV-shopping kanalen waar ge zaken kunt kopen waar ge zonder moeite/inspanning mee afvalt, never gonna happen :p
Klik om te vergroten...
Wat is er mis met nhibernate? Ik zal die toolkit is bekijken maar tot nu toe heb ik alles al redelijk snel kunnen doen via die fluent nhibernate. Gewoon mijn datamodel definieren in C#, een mapping maken in C# en met de juiste parameters mijn session aanmaken en 20 minuten later was zowel het aanmaken van een nieuwe database als het aanpassen van mijn tabel structuur al werkend. En dat is eigenlijk waar ik naar op zoek was.

edit: op het eerste zicht moet ik in die bltoolkit zelf mijn sql queries schrijven. Dat kan ik vermijden met die nhibernate, dus dat vind ik daar al een positief punt. Het zijn ook geen complexe dingen die ik moet gaan doen. Ik heb vooral lijsten met afzonderlijke data. Momenteel gebeurt alles via een binair data formaat, maar het is aan een herwerking toe voor een nieuwe versie van de software en bijkomende vereisten. Ik heb geen ingewikkelde inner joins en whatnot nodig. Gewoon enkele data velden.
M

Moto

Legacy Member
Wat is er mis met nhibernate?
Klik om te vergroten...
De vraag is, wat is er mis met mensen die nhibernate kiezen,
Wat is er mis met de DB te maken aan de hand van classes

maarja we dwalen af, misschiens dat voor een kleine projectje met weinig data en voorlopig geen complexe dingen nhibernate wel werkt, zonder echt tijd te investeren in optimalisatie.

Indien het project uitbreidt of complexer wordt of bij een nieuw groter project zal nhibernate niet meer voldoen of problemen geven op performance gebied en dan kunt ge dus lekker veel tijd uittrekken om dat te optimaliseren, ofwel al de geinvesteerde tijd in nhibernate weggooien en iets simpelers te gebruiken zoals bltoolkit

op het eerste zicht moet ik in die bltoolkit zelf mijn sql queries schrijven
Klik om te vergroten...
nee -> Data.Linq - Business Logic Toolkit for .NET

Anyway hier op het werk weer een project dat aan het falen is dankzij hibernate :)
+ DB-design gemaakt door OO-programeurs ( = slecht )
+ grote object trees vullen ( = N+1 select )
= Epic fail
T

Tyfius

Legacy Member
Moto zei:
De vraag is, wat is er mis met mensen die nhibernate kiezen,
Wat is er mis met de DB te maken aan de hand van classes

maarja we dwalen af, misschiens dat voor een kleine projectje met weinig data en voorlopig geen complexe dingen nhibernate wel werkt, zonder echt tijd te investeren in optimalisatie.

Indien het project uitbreidt of complexer wordt of bij een nieuw groter project zal nhibernate niet meer voldoen of problemen geven op performance gebied en dan kunt ge dus lekker veel tijd uittrekken om dat te optimaliseren, ofwel al de geinvesteerde tijd in nhibernate weggooien en iets simpelers te gebruiken zoals bltoolkit


nee -> Data.Linq - Business Logic Toolkit for .NET

Anyway hier op het werk weer een project dat aan het falen is dankzij hibernate :)
+ DB-design gemaakt door OO-programeurs ( = slecht )
+ grote object trees vullen ( = N+1 select )
= Epic fail
Klik om te vergroten...
Door die linq provider ziet het er al een pak interessanter uit. Nu zou die alleen nog een UpdateSchema functie moeten hebben zoals nhibernate zodat ik niet zelf alle ALTER TABLE queries moet gaan schrijven voor mijn SQLite database. Dat zou het compleet maken.
I

Ice

Legacy Member
Moto zei:
Niet mogelijk, en als er dingen bestaan die dat "verkopen", wil ik het wel horen ze :p
Zie dat eerder als die dingen op TV-shopping kanalen waar ge zaken kunt kopen waar ge zonder moeite/inspanning mee afvalt, never gonna happen :p
Klik om te vergroten...
Vreemd. in ons framework hier kan ik kolommen toevoegen / wijzigen aan mijn model een een db upgrade starten vanuit mijn applicatie.

Dan worden de juiste kolommen toegevoegd, gewijizgig en eventueel ontwikkelde upgradescripts uitgevoerd. Dus niet meteen beginnen roepen dat iets niet mogelijk is omdat je het niet kent :P
M

Moto

Legacy Member
Dan worden de juiste kolommen toegevoegd, gewijizgig en eventueel ontwikkelde upgradescripts uitgevoerd. Dus niet meteen beginnen roepen dat iets niet mogelijk is omdat je het niet kent :P
Klik om te vergroten...
Tja enigste waar ik NHibernate van ken is van al de gefaalde projecten die ik tegenkom.
Misschiens dat dat in uw framework wel werkt, maar met welke beperkingen dan..
Dingen, zeker zoals hier beschreven zullen maar enkel in een beperkte context, en met beperkte requirements kunnen werken.
T

Tyfius

Legacy Member
Ik ben 99% zeker dat ik alleen in de situatie ga komen waarbij ik velden of tabellen aan een database moet toevoegen. Dus idealiter heb ik ofwel een volledige .NET oplossing zoals fluent nhibernate, ofwel iets waarbij ik via sqliteadmin mijn db aanmaak, die ship met mijn applicatie en een framework voor mij dan een update uitvoert van de vorige database versie naar de nieuwe zonder dat ik allerlei queries moet gaan schrijven.

Ik heb ook geen ingewikkelde data. Het is allemaal vrij simpel en de bewerkingen die ik daar op moet doen ook. Ik heb geen joins of subqueries nodig op dit moment. Recht toe recht aan data wegschrijven en ophalen die weinig met elkaar te maken heeft.
P

Parnakra

Legacy Member
Misschien mis ik volledig je bedoeling, maar als je gebruik maakt van het Entity framework kan je toch makkelijk je domein of DB aanpassen en de veranderingen propageren naar de andere?

/edit: zoals blijkbaar al vermeld werd.
T

Tyfius

Legacy Member
Ik heb een desktop applicatie en een SQLite database. Geen website of iets dat op een centrale server runned. Ik moet ook werken met verschillende database files die op verschillende locaties kunnen staan op de PC van de gebruiker. Entity wise heb ik daar nog geen deftige voorveelden van gevonden.

Idealiter ship ik met mijn applicatie versie 1 een aantal (2-3) pre-made SQLite database files. Bij het starten kopieer ik deze dan naar een aantal specifieke locaties wanneer deze nog niet zouden bestaan. Een van deze files bevat een Player (name, age). In versie 2 voeg ik aan mijn database file in de Player tabel een extra field toe. Player (name, age, level). Ik moet dus al mijn bestaande data overzetten. Ik kan zelf een ALTER TABLE query schrijven, maar dat wil ik vermijden. Met Fluent NHibernate volstaat het voorlopig om een UpdateSchema functie aan te roepen die dat voor mij gaat doen. Als ik dat met BLToolkit of Entity zelf ook kan, dan is dat voldoende. Als ik ergens een soort van diff kan genereren tussen 2 database files, die ship en dan die kan loaden en applyen, ook goed. Zolang ik zelf geen ALTER TABLE queries moet gaan schrijven.

Dat is een beetje het opzet.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan