[C#] SQL Database vragen

[Stekeltje]

Ik heb een aantal vragen over een SQL database. Ik ben bezig een stukje software te maken voor mijn werk waarin ik producten in een database heb staan.

In de database is opgeslagen welke devices we hebben en wanneer ze voor het laatst zijn gekalibreerd. Bv, 01/01/2010.

Nu is het de bedoel dat er een notificatie scherm komt met de producten die binnen nu en 2 weken over due zijn. Ik wil uit de database weten welke datum er aan een product zit:

Bijvoorbeeld:
Productnrm apparaat calibratiedatum calibratiedue cabstatus
Product0001 apparaatx 01/01/2009 01/01/2010 true

Nu is het belangrijk dat ik due weet, en dat ik er berekeningen mee uitgevoerd kunnen worden. Bijvoorbeeld als het verschil met de huidige datum <14 dagen is. Dan moet ik er iets mee kunnen doen.

Ik werk met: Visual Studio C# express op een windows 7 omgeving
De database is een acces(mdf) database.

Ik hoop dat jullie me verder kunnen helpen hoe ik fatsoenlijk gegevens uit de database trek. Is er een manier om de datum weer te geven als een integer zodat ik de huidige datum kan omzetten naar een integer en dat ik ze van elkaar kan aftrekken ofzo?

Please enlighten me, dit is de eerste keer dat ik met C# werk en met databases dus het is allemaal veel uitzoeken maar dit lukt niet zo snel helaas .

[Greyfox]

Je kunt ipv de datum het aantal ticks opslaan, rekent makkelijk en snel en voor display zet je het weer om naar datum.
Wel rekening houden met conversie als je over tijdzones heen gaat.

Waarom gebruik je trouwens access en niet SQL Express?

[Stekeltje]

Greyfox schreef op donderdag 14 oktober 2010 @ 10:04:
Je kunt ipv de datum het aantal ticks opslaan, rekent makkelijk en snel en voor display zet je het weer om naar datum.
Wel rekening houden met conversie als je over tijdzones heen gaat.

Waarom gebruik je trouwens access en niet SQL Express?

Ik heb een database aangemaakt in Visual Studio, daarmee heb je gelijk ook handige plugins. De connectie tussen mijn progje en de database gaat wel met SQL express 3,5 compact (kan dat ?).

Je kunt ipv de datum het aantal ticks opslaan, rekent makkelijk en snel en voor display zet je het weer om naar datum.

Wat bedoel je met ticks? Het is belangrijk dat die datum die in de database staat de datum is waar je van uitgaat.

Zodra ik de apparten heb die 13 dagen voordat ze gekalibreerd moeten zijn een speciale waarde geef kan ik ze boven aan een lijst laten verschijnen en vanuit dat scherm weer na een ander scherm laten gaan (na een dubbelklik) waarin ze procedures kunnen ophalen.

[Voor 32% gewijzigd door Stekeltje op 14-10-2010 10:13]

[RobIII]

Er zijn toch gewoon datetime functies als DATEDIFF e.d. En SQL Express kent dat net zo goed.
Dan krijg je iets als:

SQL:

...
where datediff("d", veld_a, now())>=14
...

Greyfox schreef op donderdag 14 oktober 2010 @ 10:04:
Je kunt ipv de datum het aantal ticks opslaan

Never-ever doen. Gegevens opslaan zoals ze zijn. Een datum = datetime. Een aantal = int. Jezelf in rare bochten gaan wringen om maar de juiste gegevens eruit te krijgen is 99 v.d. 100 keer dom.

Greyfox schreef op donderdag 14 oktober 2010 @ 10:04:
Wel rekening houden met conversie als je over tijdzones heen gaat.

Daar heb je 't al...

[Voor 199% gewijzigd door RobIII op 14-10-2010 10:17]

[DayneMic]

Waarom zou je dat willen het is vrij eenvoudig.

Zorg dat de datum in de database als DateTime wordt opgeslagen.
Berekeningen met DateTime kun je namelijk heel erg gemakkelijk in C# doen.
Een voorbeeldje:

DateTime dueDate = (DateTime)sqlDataReader["dueDate"];
DateTime now = DateTime.Now;

TimeSpan difference = dueDate - now;

Je kunt vervolgens uitlezen wat het verschil in uren / minuten / seconden is door:
Int32 differenceInMinutes = difference.Minutes;

[Greyfox]

Dat het een MDF is houdt niet automatisch in dat het een Access database is, volgens mij is het dan een SQL Express database.
Voor beheer kun je daarvoor trouwens ook een gratis Management Studio downloaden.

[RobIII]

Greyfox schreef op donderdag 14 oktober 2010 @ 10:11:
Dat het een MDF is houdt niet automatisch in dat het een Access database is, volgens mij is het dan een SQL Express database.

Access = mdb, SQL Server (Express) = mdf + ldf ( + nog wat zaken als je partitioning gebruikt e.d.)

[Hydra]

DayneMic schreef op donderdag 14 oktober 2010 @ 10:10:
Waarom zou je dat willen het is vrij eenvoudig.

Zorg dat de datum in de database als DateTime wordt opgeslagen.
Berekeningen met DateTime kun je namelijk heel erg gemakkelijk in C# doen.
Een voorbeeldje:

DateTime dueDate = (DateTime)sqlDataReader["dueDate"];
DateTime now = DateTime.Now;

TimeSpan difference = dueDate - now;

Je kunt vervolgens uitlezen wat het verschil in uren / minuten / seconden is door:
Int32 differenceInMinutes = difference.Minutes;

Ja, of je doet dat gewoon in je SQL query in plaats van dat je je app uit laat vogelen wat de rows met de juiste timediff zijn?

[DayneMic]

Ligt eraan hoe je programmeert he.
Ik ben zelf meer een voorstander van Linq en Entity Framework, en dat soort berekeningen door c# uit te laten voeren.
In mijn ogen is dat toch meer schaalbaar dan weet ik veel hoeveel sp's. Uiteraard als je een fan van sp's of sql query's bent dan zou je dit inderdaad door sql server kunnen laten berekenen.
Wat ik in ieder geval uit de post van de TS begreep is dat hij in c# wilt gaan berekenen wat het tijdsverschil is.

[Greyfox]

Wat bedoel je met ticks? Het is belangrijk dat die datum die in de database staat de datum is waar je van uitgaat.

Ticks zijn het aantal 100 nanoseconde eenheden geteld vanaf 1/1/001, opgeslagen als long datatype.
Als je veel berekeningen met tijd moet doen en performance is belangrijk dan is werken met longs veel sneller dan met date-time.

Aangezien dat bij jou niet van toepassing is, ben ik nu van mening dat je ook gewoon de datum als datetime in de database zou moeten opslaan.
Ook voor de leesbaarheid van je data in de database.

[creator1988]

DayneMic schreef op donderdag 14 oktober 2010 @ 13:04:
Ligt eraan hoe je programmeert he.
Ik ben zelf meer een voorstander van Linq en Entity Framework, en dat soort berekeningen door c# uit te laten voeren.
In mijn ogen is dat toch meer schaalbaar dan weet ik veel hoeveel sp's. Uiteraard als je een fan van sp's of sql query's bent dan zou je dit inderdaad door sql server kunnen laten berekenen.
Wat ik in ieder geval uit de post van de TS begreep is dat hij in c# wilt gaan berekenen wat het tijdsverschil is.

W.T.F.

code:

SELECT * FROM GroteTabel WHERE datum BETWEEN '2010/10/14'  and '2010/10/15'

vs.

code:

var data = Dao.AllesUitGroteTabel();
foreach(var item in data)
   if(item.Datum >= new DateTime(2010, 10, 14) && item.Datum <= new DateTime(2010, 10, 15))
       AddToOutputlist(item);

wat is schaalbaarder?

[Voor 22% gewijzigd door creator1988 op 14-10-2010 13:17]

[Woy]

Greyfox schreef op donderdag 14 oktober 2010 @ 13:15:
[...]
Als je veel berekeningen met tijd moet doen en performance is belangrijk dan is werken met longs veel sneller dan met date-time.

Dat vind ik nogal een sterke bewering. Intern word een datetime waarschijnlijk zelfs al op een dergelijke manier opgeslagen, en ik ga er vanuit dat de datetime functions gewoon snel geïmplementeerd zijn. Er zijn dan misschien een paar cases waar je met een long wel sneller rekend, maar dat komt dan vooral omdat je niet goed rekening houd met alle uitzonderingen met tijdzone's/zomer/wintertijd etc.

Als je echt tegen performance problemen aanloopt wat betreft het rekenen met datum's dan kun je die waarschijnlijk beter op een andere manier oplossen.

[Stekeltje]

Woy schreef op donderdag 14 oktober 2010 @ 14:25:
[...]

Dat vind ik nogal een sterke bewering. Intern word een datetime waarschijnlijk zelfs al op een dergelijke manier opgeslagen, en ik ga er vanuit dat de datetime functions gewoon snel geïmplementeerd zijn. Er zijn dan misschien een paar cases waar je met een long wel sneller rekend, maar dat komt dan vooral omdat je niet goed rekening houd met alle uitzonderingen met tijdzone's/zomer/wintertijd etc.

Als je echt tegen performance problemen aanloopt wat betreft het rekenen met datum's dan kun je die waarschijnlijk beter op een andere manier oplossen.

creator1988 schreef op donderdag 14 oktober 2010 @ 13:15:
[...]


W.T.F.

code:

SELECT * FROM GroteTabel WHERE datum BETWEEN '2010/10/14'  and '2010/10/15'

vs.

code:

var data = Dao.AllesUitGroteTabel();
foreach(var item in data)
   if(item.Datum >= new DateTime(2010, 10, 14) && item.Datum <= new DateTime(2010, 10, 15))
       AddToOutputlist(item);

wat is schaalbaarder?

Het draait niet echt om performance, het is een database met +/- 150 apparaten, misschien met een uitbreiding in de toekomst voor een klanten bestand.

Het is belangrijk hoe ik de datum uit de database kan plukken zodat ik er of in de code mee verder kan rekenen (dus de datum code uit je post) of dat er al een kant en klaar getal uit de database komt.

Als dat zo is dan kan ik met de uitkomst bepalen of een apparaat moet worden weer gegeven in het notificatie scherm.

[DayneMic]

creator1988 schreef op donderdag 14 oktober 2010 @ 13:15:
[...]


W.T.F.

code:

SELECT * FROM GroteTabel WHERE datum BETWEEN '2010/10/14'  and '2010/10/15'

vs.

code:

var data = Dao.AllesUitGroteTabel();
foreach(var item in data)
   if(item.Datum >= new DateTime(2010, 10, 14) && item.Datum <= new DateTime(2010, 10, 15))
       AddToOutputlist(item);

wat is schaalbaarder?

Als jij een goede DAL met BLL opzet dan is dat zeker meer schaalbaar dan 100 van dat soort losse query's in je code of aan elkaar geplakt met sp's. 1 op 1 zou een losse query misschien sneller zijn maar dan denk ik niet dat je helemaal begrijpt wat schaalbaar in deze context inhoudt. Waarom gebruik je überhaupt een foreach?

code:

DateTime iets = DateTime(2010, 10, 14);
DateTime nogIets = DateTime(2010, 10, 15);

List<entityUitDatabase> outPutCollectionBetweenDates = bll.dataUitTabel.Where(x => x.Datum => iets && x.Datum <= nogIets).ToList();

Waar je de nieuwe outPutCollectionBetweenDates nog verder uit kunt filteren en door kunt geven aan een nieuwe bll mocht dat nodig zijn.
Dus jij zou dan liever allemaal queries gaan schrijven om iets van extra functionaliteit te implementeren?

[Greyfox]

Woy schreef op donderdag 14 oktober 2010 @ 14:25:
[...]

Dat vind ik nogal een sterke bewering. Intern word een datetime waarschijnlijk zelfs al op een dergelijke manier opgeslagen, en ik ga er vanuit dat de datetime functions gewoon snel geïmplementeerd zijn.

Als je echt tegen performance problemen aanloopt wat betreft het rekenen met datum's dan kun je die waarschijnlijk beter op een andere manier oplossen.

Met 'waarschijnlijk' en 'ik ga er vanuit' heb je ook niet echt een sterke case.

Maar wat zouden jouw oplossingen dan zijn als je tegen performance problemen aanloopt op gebied van rekenen met datums?

[Stekeltje]

Greyfox schreef op donderdag 14 oktober 2010 @ 15:09:
[...]


Met 'waarschijnlijk' en 'ik ga er vanuit' heb je ook niet echt een sterke case.

Maar wat zouden jouw oplossingen dan zijn als je tegen performance problemen aanloopt op gebied van rekenen met datums?

Misschien is er een MB'tje nodig. Ik heb dit topic niet geopend om te discussieren over de performance van data. Dit topic is bedoeld om te kunnen rekenen met de data zonder dat er rekening mee gehouden moet worden of het hele zaakje snel is of niet.

(Sorry, ik ben blij dat mensen willen helpen, het is alleen jammer dat het topic gewoon een andere kant op vliegt)

[Woy]

Greyfox schreef op donderdag 14 oktober 2010 @ 15:09:
[...]
Met 'waarschijnlijk' en 'ik ga er vanuit' heb je ook niet echt een sterke case.

Dat is natuurlijk platform afhankelijk, en daarom kan ik het niet met zekerheid zeggen voor alle platforms. Maar in bijvoorbeeld het .net framework word er intern gewoon met Ticks gerekend.

Maar wat zouden jouw oplossingen dan zijn als je tegen performance problemen aanloopt op gebied van rekenen met datums?

Dat is situatie afhankelijk. Als je zoals hier bijvoorbeeld datums binnen een range wil hebben, dan kun je gewoon de randwaarden berekenen, en alleen een groter/kleiner test doen. Je hebt dan nog maar 2 berekeningen met datum's en de rest zijn gewoon vergelijkingen.

...Ruud... schreef op donderdag 14 oktober 2010 @ 15:14:
[...]

Misschien is er een MB'tje nodig. Ik heb dit topic niet geopend om te discussieren over de performance van data. Dit topic is bedoeld om te kunnen rekenen met de data zonder dat er rekening mee gehouden moet worden of het hele zaakje snel is of niet.

(Sorry, ik ben blij dat mensen willen helpen, het is alleen jammer dat het topic gewoon een andere kant op vliegt)

Maar misschien moet jij dan wat duidelijker aangeven wat je daadwerkelijke probleem is. Ik neem aan dat je weet hoe SQL werkt, en er is ook genoeg informatie te vinden op internet over hoe je een query uitvoert d.m.v. C#. Waar loop je tegen problemen aan?

[Voor 32% gewijzigd door Woy op 14-10-2010 15:19]

[whoami]

DayneMic schreef op donderdag 14 oktober 2010 @ 15:06:
[...]


Als jij een goede DAL met BLL opzet dan is dat zeker meer schaalbaar dan 100 van dat soort losse query's in je code of aan elkaar geplakt met sp's. 1 op 1 zou een losse query misschien sneller zijn maar dan denk ik niet dat je helemaal begrijpt wat schaalbaar in deze context inhoudt. Waarom gebruik je überhaupt een foreach?

code:

DateTime iets = DateTime(2010, 10, 14);
DateTime nogIets = DateTime(2010, 10, 15);

List<entityUitDatabase> outPutCollectionBetweenDates = bll.dataUitTabel.Where(x => x.Datum => iets && x.Datum <= nogIets).ToList();

Waar je de nieuwe outPutCollectionBetweenDates nog verder uit kunt filteren en door kunt geven aan een nieuwe bll mocht dat nodig zijn.
Dus jij zou dan liever allemaal queries gaan schrijven om iets van extra functionaliteit te implementeren?

Laat mij even stellen dat een goede DAL en een goede BLL impliceert dat de DAL 'zijn' taken uitvoert, en de BLL ook 'zijn' taken uitvoert.

Dat wil zeggen: filteren van data gebeurt door de DAL, en niet door de BLL of front-end.
Je gaat toch niet je hele DB leegtrekken, alle gegevens over de lijn sturen, om dan maar met LINQ te kunnen gaan filteren, omdat dat hip zou zijn ?

Nee, je gaat je DAL (en of je nu Entity Framework, NHibernate, whatever gebruikt) die data laten filteren.

Trouwens: ivm die foreach, wat denk je dat die Where LINQ extension method intern zal doen ?
(Tenzij je LINQ to SQL of een dergelijke implementatie gebruikt, die de boel omzet naar de juiste SQL statements, maar dan is er iets mis met je layering, want dan doe jij in je front-end data-access.

[whoami]

Greyfox schreef op donderdag 14 oktober 2010 @ 15:09:
[...]


Met 'waarschijnlijk' en 'ik ga er vanuit' heb je ook niet echt een sterke case.

Maar wat zouden jouw oplossingen dan zijn als je tegen performance problemen aanloopt op gebied van rekenen met datums?

Ik denk dat dit een micro-optimalisatie is. Zoals Woy al aangeeft, hebben de meeste performance problemen hun oorzaak in structurele bepalingen.

Als je een long gaat gebruiken ipv een datetime, omdat dit sneller zou zijn, dan is dat imho een micro-optimalisatie.
Een datetime wordt in de meeste omgevingen trouwens toch intern voorgesteld als een een long of een combinatie van 2 floats.
Gebruik altijd het juiste datatype; dat zorgt voor het minste problemen qua onderhoud, leesbaarheid en ook qua performantie.

[whoami]

...Ruud... schreef op donderdag 14 oktober 2010 @ 15:14:
[...]

Misschien is er een MB'tje nodig. Ik heb dit topic niet geopend om te discussieren over de performance van data. Dit topic is bedoeld om te kunnen rekenen met de data zonder dat er rekening mee gehouden moet worden of het hele zaakje snel is of niet.

(Sorry, ik ben blij dat mensen willen helpen, het is alleen jammer dat het topic gewoon een andere kant op vliegt)

Wat is het specifieke probleem dan ?

hoe trek je data uit de DB ?
Wil je gebruik maken van plain ADO.NET ? Kijk dan eens naar de System.Data & System.Data.SqlClient namespaces.
Meer bepaald de DbCommand (SqlCommand), DbConnection, DataReader, DataAdapter etc... classes.
Met deze classes kan je SQL statements op je DB loslaten, en de gegevens die teruggegeven worden, uitlezen.

Kijk ook naar -zoals RobIII- al aangeeft, welke datetime functies het DBMS dat je gebruikt beschikbaar stellen, zodanig dat je deze al in je SQL statements kunt gebruiken.

Je kan ook gebruik gaan maken van een O/R mapper als Entity Framework of NHibernate, maar ik denk dat dit overkill is in jouw situatie; zeker als je de leercurve in beschouwing neemt.


Verder: hoort dit topic dan niet meer in PRG ipv in SEA ?

[Stekeltje]

Woy schreef op donderdag 14 oktober 2010 @ 15:16:
[...]

Dat is natuurlijk platform afhankelijk, en daarom kan ik het niet met zekerheid zeggen voor alle platforms. Maar in bijvoorbeeld het .net framework word er intern gewoon met Ticks gerekend.


[...]

Dat is situatie afhankelijk. Als je zoals hier bijvoorbeeld datums binnen een range wil hebben, dan kun je gewoon de randwaarden berekenen, en alleen een groter/kleiner test doen. Je hebt dan nog maar 2 berekeningen met datum's en de rest zijn gewoon vergelijkingen.

[...]

Maar misschien moet jij dan wat duidelijker aangeven wat je daadwerkelijke probleem is. Ik neem aan dat je weet hoe SQL werkt, en er is ook genoeg informatie te vinden op internet over hoe je een query uitvoert d.m.v. C#. Waar loop je tegen problemen aan?

Nou dit is eigenlijk de eerste keer dat ik iets probeer met een database. Mijn vraag is hoe je een datum (welke variable waarschijnlijk) ik moet aangeven voor een datum.

Ik gebruik nu een filter "=?" en dan verschijnt er "= @Param1" maar dan krijg ik een parse error. Als ik de berekening uitvoer die hier in het topic staat.

Even voor de duidelijkheid: Ik heb weinig tot geen ervaring met SQL databases maar ik hoop dat jullie me wat beter kunnen 'enlighten'

[Greyfox]

Dat is natuurlijk platform afhankelijk, en daarom kan ik het niet met zekerheid zeggen voor alle platforms. Maar in bijvoorbeeld het .net framework word er intern gewoon met Ticks gerekend.

Om het topic rondom snelheid en datums af te sluiten, dit vond ik over SQL Server:

As you know, the datetime data type occupies eight bytes: four to store the number of days before or after January 01, 1900 and four more for the number of 3.33ms clock ticks since midnight. The smalldatetime data type needs only four bytes as it is less precise than datetime; it stores the number of days since January 01, 1900 and the number of minutes since midnight. All the numbers are stored as integers. So when you run SELECT GETDATE() + 1, you actually add datetime data to the integer number. Since the datetime data type has higher precedence, the integer number 1 (as an addend with lower precedence) has to be implicitly converted to a data type of the addend with higher precedence.

Punt voor jou en ik wat geleerd.
Misschien dat het met heel high volume/performance wat uitmaakt of je datetime of long hebt, maar per saldo zal dat meer liggen aan de functies die je gebruikt dan aan het data type.

[DayneMic]

whoami schreef op donderdag 14 oktober 2010 @ 15:17:
[...]

Laat mij even stellen dat een goede DAL en een goede BLL impliceert dat de DAL 'zijn' taken uitvoert, en de BLL ook 'zijn' taken uitvoert.

Dat wil zeggen: filteren van data gebeurt door de DAL, en niet door de BLL of front-end.
Je gaat toch niet je hele DB leegtrekken, alle gegevens over de lijn sturen, om dan maar met LINQ te kunnen gaan filteren, omdat dat hip zou zijn ?

Nee, je gaat je DAL (en of je nu Entity Framework, NHibernate, whatever gebruikt) die data laten filteren.

Trouwens: ivm die foreach, wat denk je dat die Where LINQ extension method intern zal doen ?
(Tenzij je LINQ to SQL of een dergelijke implementatie gebruikt, die de boel omzet naar de juiste SQL statements, maar dan is er iets mis met je layering, want dan doe jij in je front-end data-access.

Het eerste gedeelte klopt. Een DAL en BLL hebben zo allebei hun eigen taken. Uiteraard haal je met de DAL data op die voldoet aan bepaalde criteria, dat spreekt voor zich. De BLL haald deze data netjes op voor je en maakt dit bruikbaar voor je presenter. Het is niet meer dan normaal dat je een BLL method nog voor het ophalen naar een presenter wilt uitfilteren of limiteren dus jou aanname om je hele DB leeg te trekken naar je DAL of hoe je er bij komt dat ik in de frontend data-access zou gebruiken vind ik vreemd. Als je goed naar de linq query had gekeken had je kunnen zien dat dit een query is dat gedaan wordt binnen een EF data context. Als je weleens EF hebt gebruikt met sql profiler zul je ook zien dat als je een goede Where opdracht geeft dit prima omgezet wordt naar nette sql statements die de door jou opgegeven entities teruggeeft ergo niet de hele database. Ik vind het alleen wel bad practice inderdaad om nog een foreach te gaan doen handmatig terwijl dit zoveel mooier kan. Niet omdat 'hip' is. Maar omdat het stukken sneller ontwikkeld.

[_js_]

.

[Voor 99% gewijzigd door _js_ op 14-10-2010 15:34. Reden: anderen hebben hetzelfde al gepost]

[whoami]

Uit jouw voorbeeld is helemaal niet duidelijk dat je EF zou gebruiken.

(EF heb ik nog niet gebruikt, maar laat ons zeggen dat ik redelijk 'profound' ben in het gebruik van (N)Hibernate).

[whoami]

...Ruud... schreef op donderdag 14 oktober 2010 @ 15:24:
[...]


Nou dit is eigenlijk de eerste keer dat ik iets probeer met een database. Mijn vraag is hoe je een datum (welke variable waarschijnlijk) ik moet aangeven voor een datum.

Ik gebruik nu een filter "=?" en dan verschijnt er "= @Param1" maar dan krijg ik een parse error. Als ik de berekening uitvoer die hier in het topic staat.

Even voor de duidelijkheid: Ik heb weinig tot geen ervaring met SQL databases maar ik hoop dat jullie me wat beter kunnen 'enlighten'

code:

DateTime dt = new DateTime (2010,1,1);
var command = connection.CreateCommand();
command.CommandText = "SELECT bliep, blop FROM tabel WHERE datum = @p_datum";
command.Parameters.Add ("@p_datum", SqlDbType.DateTime).Value = dt;

using( var reader = command.ExecuteReader() )
{
    while( reader.Read() )
    {
          Console.WriteLine (reader.GetString(0));
    }
}

[DayneMic]

whoami schreef op donderdag 14 oktober 2010 @ 15:34:
Uit jouw voorbeeld is helemaal niet duidelijk dat je EF zou gebruiken.

(EF heb ik nog niet gebruikt, maar laat ons zeggen dat ik redelijk 'profound' ben in het gebruik van (N)Hibernate).

ja oke. Als je EF zou gebruiken dan zou het misschien wat duidelijker geweest zijn vanwege de entity suffix. Niet dat iedereen dat altijd gebruikt maar goed.
(N)Hibernate komt me niet zo bekend voor, ook een soort laag als EF?

[DayneMic]

whoami schreef op donderdag 14 oktober 2010 @ 15:36:
[...]

code:

DateTime dt = new DateTime (2010,1,1);
var command = connection.CreateCommand();
command.CommandText = "SELECT bliep, blop FROM tabel WHERE datum = @p_datum";
command.Parameters.Add ("@p_datum", SqlDbType.DateTime).Value = dt;

using( var reader = command.ExecuteReader() )
{
    while( reader.Read() )
    {
          Console.WriteLine (reader.GetString(0));
    }
}

code:

DateTime dt = new DateTime (2010,1,1);
var command = connection.CreateCommand();
command.CommandText = "SELECT bliep, blop FROM tabel WHERE datum = @p_datum";
command.Parameters.Add ("@p_datum", SqlDbType.DateTime).Value = dt;

using( var reader = command.ExecuteReader() )
{
    while( reader.Read() )
    {
          Console.WriteLine (reader["bliep"].ToString());
          Console.WriteLine (reader["blop"].ToString());
    }
}

porbeer dit eens

[whoami]

WTF zeg, mijn code gaat evengoed.
En als we het toch over performance issues hebben, dan wil ik even stellen dat mijn code sneller zal zijn.
En als dat allemaal mooi weg-geabstraheerd is , dan maakt het qua leesbaarheid niet zoveel uit of je nu de Getxxx method gebruikt, of gebruik maakt van de indexer waaraan je een veldnaam/alias geeft.

[DayneMic]

whoami schreef op donderdag 14 oktober 2010 @ 15:53:
WTF zeg, mijn code gaat evengoed.
En als we het toch over performance issues hebben, dan wil ik even stellen dat mijn code sneller zal zijn.
En als dat allemaal mooi weg-geabstraheerd is , dan maakt het qua leesbaarheid niet zoveel uit of je nu de Getxxx method gebruikt, of gebruik maakt van de indexer waaraan je een veldnaam/alias geeft.

Oh sorry mijn fout. rustig maar. Ik dacht dat juist die code bij hem verkeerd ging op de een of andere manier.
Dit was geen vervanging omdat ik jou code niet goed zou vinden. had de post verkeerd gezien

[Davio]

Ik zou in jouw geval LINQ to SQL gebruiken, doe ik zelf ook; ik weet niet precies hoe het zit met performance, maar voor mij is het wel het makkelijkst. En aangezien je aangaf maar 150 producten in de database te hebben, hoef je ook niet het onderste uit de tube te knijpen.

Je maakt binnen je project gewoon verbinding met de database en doet dan 'Add -> New Item -> Data -> LINQ to SQL Classes'.

Vervolgens moet je alle nodige tabellen van je Server Explorer naar je Designer slepen en dan maakt hij vanzelf de onderliggende klasses aan.


LINQ to SQL maakt het mogelijk om database-tabellen aan te spreken als .NET-objecten via een DataClassesContext.

C#:

// Je kan dan loopen over een tabel met bijvoorbeeld de code:
foreach(Product p in myDataClassesContext.Products)
{
    Console.WriteLine(p.Name);
}

// Je kan een insert doen met de code:
Product prod = new Product { Name = @"Whatever", Price = 99.99 };
myDataClassesContext.Products.InsertOnSubmit(prod);
myDataClassesContext.SubmitChanges(); // Dit niet vergeten als je een verandering maakt in de database

// Je kan ook een uitgebreide selectie doen met een LINQ-statement die er als volgt uitziet
var verlopendeProducten =
    from p in myDataClassesContext.Products
    where p.VerloopDatum <= DateTime.Now.AddDays(14)
    select p;

// Een LINQ-statement ziet er een beetje uit als een SQL-Query, maar dan omgekeerd
// En dan doe je gewoon weer foreach(Product p in verlopendeProducten).

Dit is dus de manier waarop ik het doe en in jouw geval ook zou doen. Dan laat je daadwerkelijke database-koppeling aan .NET en gebruik je de tabellen als .NET-objecten.

[whoami]

Was LINQ-to-SQL geen dead-end ?
MS ging dit toch niet meer supporteren, ten faveure van EF ?

[Jeroen V]

whoami schreef op donderdag 14 oktober 2010 @ 17:32:
Was LINQ-to-SQL geen dead-end ?
MS ging dit toch niet meer supporteren, ten faveure van EF ?

Klopt helemaal..... En gelukkig is EF4.0 weer een stuk bruikbaarder dan EF3.5. (of hoe die versies dan ook lopen )

[Hydra]

.

[Voor 99% gewijzigd door Hydra op 14-10-2010 17:44. Reden: Lama]

[Expecho]

whoami schreef op donderdag 14 oktober 2010 @ 17:32:
Was LINQ-to-SQL geen dead-end ?
MS ging dit toch niet meer supporteren, ten faveure van EF ?

wel, ligt eraan hoe je het ziet.. het werkt ok, en dat zal het ook blijven doen, er worden alleen geen nieuwe features meer ingestopt. http://www.thinqlinq.com/...nhancements-for-2010.aspx, http://damieng.com/blog/2...-to-sql-changes-in-net-40

ik gebruik het al tijden naar tevredenheid, vanwege de eenvoudige werking.

zie ook ms standpunt: http://msdn.microsoft.com/en-us/data/bb525059.aspx#Q3

[Voor 6% gewijzigd door Expecho op 14-10-2010 17:56. Reden: ms link toegevoegd]

[Caelorum]

Expecho schreef op donderdag 14 oktober 2010 @ 17:53:
[...]


wel, ligt eraan hoe je het ziet.. het werkt ok, en dat zal het ook blijven doen, er worden alleen geen nieuwe features meer ingestopt. http://www.thinqlinq.com/...nhancements-for-2010.aspx, http://damieng.com/blog/2...-to-sql-changes-in-net-40

ik gebruik het al tijden naar tevredenheid, vanwege de eenvoudige werking.

zie ook ms standpunt: http://msdn.microsoft.com/en-us/data/bb525059.aspx#Q3

Ben ik nu scheel of staat er op die laatste pagina toch duidelijk dat Microsoft wel doorgaat met de ontwikkeling van LINQ-to-SQL, maar dat de meeste ontwikkeltijd aan ENtity Framework wordt besteed. Zover ik kan zien staat er ook nergens dat ze stoppen met nieuwe functionaliteit in LINQ-to-SQL te stoppen.

Question #2: Where does Microsoft stand on LINQ to SQL?
Answer: We would like to be very transparent with our customers about our intentions for future innovation with respect to LINQ to SQL and the Entity Framework.
In .NET 4.0, we continue to invest in both technologies. Within LINQ to SQL, we made a number of performance and usability enhancements, as well as updates to the class designer and code generation. Within the Entity Framework, we listened to a great deal to customer feedback and responded with significant investments including better foreign key support, T4 code generation, and POCO support.
Moving forward, Microsoft is committing to supporting both technologies as important parts of the .NET Framework, adding new features that meet customer requirements. We do, however, expect that the bulk of our overall investment will be in the Entity Framework, as this framework is built around the Entity Data Model (EDM). EDM represents a key strategic direction for Microsoft that spans many of our products, including SQL Server, .NET, and Visual Studio. EDM-based tools, languages and frameworks are important technologies that enable our customers and partners to increase productivity across the development lifecycle and enable better integration across applications and data sources.

[Davio]

Expecho schreef op donderdag 14 oktober 2010 @ 17:53:
[...]


wel, ligt eraan hoe je het ziet.. het werkt ok, en dat zal het ook blijven doen, er worden alleen geen nieuwe features meer ingestopt. http://www.thinqlinq.com/...nhancements-for-2010.aspx, http://damieng.com/blog/2...-to-sql-changes-in-net-40

ik gebruik het al tijden naar tevredenheid, vanwege de eenvoudige werking.

zie ook ms standpunt: http://msdn.microsoft.com/en-us/data/bb525059.aspx#Q3

Bedankt voor deze post.

Ik dacht dat LINQ to SQL juist een handige nieuwe feature was van .NET 3.5 waar ze wel wat mee van plan waren; heb er ook genoeg over gelezen in hun eigen handleidingen. Maar nu gaan ze het alweer uitfaseren.

Dan stap ik maar over naar EF.

[jip_86]

Jongens, de TS werkt voor de eerste keer met C#. Dan kom je toch niet met DAL en BLL's aansjouwen
Hij wil alleen weten weten dat hij C# sql datediff in google had moeten kloppen.

[Caelorum]

Davio schreef op vrijdag 15 oktober 2010 @ 13:49:
[...]

Bedankt voor deze post.

Ik dacht dat LINQ to SQL juist een handige nieuwe feature was van .NET 3.5 waar ze wel wat mee van plan waren; heb er ook genoeg over gelezen in hun eigen handleidingen. Maar nu gaan ze het alweer uitfaseren.

Dan stap ik maar over naar EF.

Minder aandacht krijgen is wel wat anders dan uitfaseren, IMO.

[Davio]

Caelorum schreef op vrijdag 15 oktober 2010 @ 15:48:
[...]

Minder aandacht krijgen is wel wat anders dan uitfaseren, IMO.

Minder aandacht krijgen is juist het begin van uitfaseren, IMO.