[SQL] Project met zeer grote query

maandag 2 juli 2007 09:41

Volgens mij gaat het hier niet om één query, maar om een script dat verschillende INSERT statements bevat ?
Wat bedoel je met 'aanvullende' logica ?

Wat is de bedoeling van die insert-statements ?

ik merk dat ik nu al behoorlijk wat tijd kwijt ben aan het zoeken in de query naar de juiste secties.

Als het allemaal los van elkaar staande statements zijn, dan kan je toch je statements per sectie opsplitsen & in een aparte file zetten ?

https://fgheysels.github.io/

Acties:

maandag 2 juli 2007 09:47

Topicstarter

Het zijn echt allemaal verschillende databases, verspreid over twee servers en ook een paar op mijn dev systeem. Iedere database bevat klant-data, een van de redenen voor deze beslissing is dat klanten hiermee gerustgesteld zijn.
De reden dat ik het vermeld is dat ik niet veel heb aan een oplossing met Stored Procedures.

Nogmaals: ik vraag niet om security-advies maar om een project-opzet!

Voorbeeld van de code

code:

DECLARE @creativeinfo TABLE(
    adgroupid BIGINT,
    creativeid BIGINT,
    conv BIGINT,
    clicks BIGINT,
    cost BIGINT,
    imps BIGINT,
    pos FLOAT,
    convvalue FLOAT,
    date DATETIME
)
DECLARE @creativeresults TABLE(
    AdGroup NVARCHAR(64) COLLATE SQL_Latin1_General_CP1_CI_AS,
    Creative NVARCHAR(256) COLLATE SQL_Latin1_General_CP1_CI_AS,
    Pos FLOAT,
    Conv BIGINT,
    Clicks BIGINT,
    Cost FLOAT,
    Imps BIGINT,
    ConvRate FLOAT,
    CTR FLOAT,
    CPC FLOAT,
    ConvCost FLOAT,
    Value FLOAT,
    ConvValue FLOAT,
    ROI FLOAT,
    DestURL NVARCHAR(256) COLLATE SQL_Latin1_General_CP1_CI_AS
)

-- en wat verderop

INSERT INTO @creativeresults
    (AdGroup,Creative,
    Pos,Conv,Clicks,Cost,Imps,
    ConvRate,CTR,CPC,ConvCost,
    Value,ConvValue,ROI,DestURL)
SELECT
    MAX(data.adgroup) AS AdGroup,
    LEFT(MIN(data.headline) + CHAR(10) +
        MIN(data.desc1) + CHAR(10) +
        MIN(data.desc2) + CHAR(10) +
        MIN(data.creativevisurl), 256)
    AS Creative,
    MAX(bc.pos) AS Pos,
    MAX(bc.conv) AS Conv,
    MAX(bc.clicks) AS Clicks,
    MAX(bc.cost) / 1000000.0 AS Cost,
    MAX(bc.imps) AS Imps,
    CASE MAX(bc.clicks)
        WHEN 0 THEN NULL
        ELSE 1.0 * MAX(bc.conv) / MAX(bc.clicks)
    END 
    AS ConvRate,
    CASE MAX(bc.imps)
        WHEN 0 THEN NULL
        ELSE 1.0 * MAX(bc.clicks) / MAX(bc.imps)
    END
-- gaat nog een stuk verder...

-- Uiteindelijk plaatsen in een Excel Named Range ( {1} wordt vervangen)
INSERT INTO [{1}]...[Creatives]
    (AdGroup,Creative,
    Pos,Conv,Clicks,Cost,Imps,
    ConvRate,CTR,CPC,ConvCost,
    Value,ConvValue,ROI,URL)
SELECT * FROM @creativeresults

Er wordt dus gewerkt met tijdelijke tabellen die een basis vormen voor de eindresultaten. Deze worden in de Excel geplaatst.

Het splitsen in meerdere queries die je aan elkaar plakt is niet echt handig, omdat er definities zijn (zoals tijdelijke tabellen) die worden hergebruikt.

Acties:

maandag 2 juli 2007 09:56

Topicstarter

Verwijderd schreef op maandag 02 juli 2007 @ 04:12:
[...]
vind je helemaal geweldig, dat je daar aan gewerkt hebt. Je bent zo goed dat je
aan dat soort projecten werkt, en toch je vraag op een openbaar forum moet stellen??

vertel nu eens ff je probleem, want de glazen bollen zijn weer eens op hier ....

In andere programmeeromgevingen heb ik de beschikking over abstractievormen: aparte functies, classes, dlls, exes. Hiermee wordt een project schaalbaar.
Binnen SQL zie ik alleen Stored Procedures, en deze gebruik ik liever niet - er is sprake van meerdere databases en servers, en dan moet ik de SPs synchroon houden.

Het probleem is dus, hoe creeer ik een grote SQL query die toch beheersbaar is?

Acties:

Verwijderd

Free rider schreef op maandag 02 juli 2007 @ 09:47:
Binnen SQL zie ik alleen Stored Procedures, en deze gebruik ik liever niet

Wat is er mis met het aanmaken van stored procedures/functions? Dit is toch een prima scenario om gebruik te maken van dergelijke functionaliteit?

maandag 2 juli 2007 09:59

Acties:

maandag 2 juli 2007 10:08

Topicstarter

whoami schreef op maandag 02 juli 2007 @ 08:46:
Volgens mij gaat het hier niet om één query, maar om een script dat verschillende INSERT statements bevat ?

In principe heb je gelijk. Maar uiteindelijk wordt er een 'script' naar de database gestuurd. Het versturen van meerdere scripts achter elkaar lijkt me niet zo zinvol, dat beperkt alleen maar de optimalizaties van SQL Server.

Wat bedoel je met 'aanvullende' logica ?
Wat is de bedoeling van die insert-statements ?

De aanvullende logica is de meerwaarde! Het is iets anders dan SELET * FROM [adventureworks]. Uiteindelijk is het een soort rapportage-tool, waarbij diverse Named Ranges in een Excel-bestand worden gevuld. De afnemers hebben graag de resultaten in Excel.

[...]
Als het allemaal los van elkaar staande statements zijn, dan kan je toch je statements per sectie opsplitsen & in een aparte file zetten ?

Klopt maar of de logica nou staat in een bestand van 1500 regels of 15 bestanden van 100 regels maakt niet uit. Ik zoek een logische indeling, met vormen van abstractie enz.

Acties:

maandag 2 juli 2007 10:08

Free rider schreef op maandag 02 juli 2007 @ 09:59:
[...]

In principe heb je gelijk. Maar uiteindelijk wordt er een 'script' naar de database gestuurd. Het versturen van meerdere scripts achter elkaar lijkt me niet zo zinvol, dat beperkt alleen maar de optimalizaties van SQL Server.

Als in .... ?

Hoeveel keer moet die script uitgevoerd worden ? 1x per DB ?

Trouwens, de temp tables waar jij over spreekt, zijn geen temp tables. Het zijn variablen.
Als je een echte temp table gebruikt (CREATE TABLE #temptablenaam), dan blijft die tabel gedurende je ganse sessie (connectie) bestaan. Dus, dat is geen probleem om over meerdere files te gaan splitten.

Klopt maar of de logica nou staat in een bestand van 1500 regels of 15 bestanden van 100 regels maakt niet uit. Ik zoek een logische indeling, met vormen van abstractie enz.

En nu verwacht je dat we, op basis van de zeer beperkte informatie die je hier geeft, wij die abstractie ff voor jou tevoorschijn kunnen toveren ?

[ Voor 18% gewijzigd door whoami op 02-07-2007 10:10 ]

https://fgheysels.github.io/

Acties:

d00d

geen matches

Tja, stored procedures en user defined functions zijn toch echt de manier om een abstractielaag te maken in SQL Server. Je kunt ook gebruik maken van de .Net Framework CLR, maar aangezien je de SQL al hebt lijkt me dit niet handig.

Als tip heb ik nog wel het volgende: als de layout van de databases (ongeveer) gelijk is dan kun je de stored procedures ook prefixen met sp_ en ze in de master database plaatsen. Dit zorgt ervoor dat de procedures draaien in de context van de database waaruit ze worden aangeroepen.

Eigenlijk is dit niet heel netjes, maar het zorgt er wel voor dat je de procedures maar een keer hoeft aan te maken en dat is goed voor de onderhoudbaarheid.

42.7 percent of all statistics are made up on the spot.

maandag 2 juli 2007 10:09

Acties:

maandag 2 juli 2007 10:26

Topicstarter

Verwijderd schreef op maandag 02 juli 2007 @ 09:56:
Wat is er mis met het aanmaken van stored procedures/functions? Dit is toch een prima scenario om gebruik te maken van dergelijke functionaliteit?

Twee redenen:
1. De query is vooral ontwikkeld in SQL Server Mgmt studio. Het is lastig om zowel de query als SPs tegelijk aan te passen.
2. Ik vrees een beheersprobleem van de SPs - er zijn meerdere servers en databases. Daarbij heb ik altijd het idee dat SPs meer een onderdeel van de database zijn, en niet van de applicatie.

Ik realiseer me dat vooral de eerste reden kort door de bocht is. Maar vooralsnog zie ik alleen dat je SP kan bewerken door een CREATE PROCEDURE statement te bewerken - niet erg vriendelijk volgens mij.

[ Voor 7% gewijzigd door Free rider op 02-07-2007 10:15 ]

Acties:

maandag 2 juli 2007 10:43

Topicstarter

whoami schreef op maandag 02 juli 2007 @ 10:08:
[...]
Als in .... ?

Hoeveel keer moet die script uitgevoerd worden ? 1x per DB ?

Trouwens, de temp tables waar jij over spreekt, zijn geen temp tables. Het zijn variablen.
Als je een echte temp table gebruikt (CREATE TABLE #temptablenaam), dan blijft die tabel gedurende je ganse sessie (connectie) bestaan. Dus, dat is geen probleem om over meerdere files te gaan splitten.

Je hebt helemaal gelijk over die tabellen.
Maar ik submit liever de query in een keer, zodat SQL Server zelf de beste strategie kan bepalen.

[...]
En nu verwacht je dat we, op basis van de zeer beperkte informatie die je hier geeft, wij die abstractie ff voor jou tevoorschijn kunnen toveren ?

Ik hoop dat iemand naar voren komt die zelf een query van 10.000 regels heeft onderhouden en vertelt hoe hij ermee omgaat. Of een verwijzing naar een project met zo'n query.

Acties:

Verwijderd

Free rider schreef op maandag 02 juli 2007 @ 10:09:
2. Ik vrees een beheersprobleem van de SPs - er zijn meerdere servers en databases. Daarbij heb ik altijd het idee dat SPs meer een onderdeel van de database zijn, en niet van de applicatie.

1 vond je zelf al te kort door de bocht, dus dan punt 2:
Ja ze zijn wat lastiger te beheren, maar je hebt er al voor gekozen om de logica in sql uit te voeren door immense queries te bouwen. Dus waarom die immense queries niet wat versimpelen vaste patronen onder te brengen in SPs? Je kunt SPs zo schrijven dat je ze nauwelijks hoeft te beheren, denk hierbij aan het gebruik van '%rowtype' als argument i.p.v. specifieke velden. Ik denk dus dat je je ook niet teveel moet focussen op de beheersbaarheid. Het is altijd die gulde middenweg waar je een beetje doorheen moet zien te schipperen.

maandag 2 juli 2007 10:46

Acties:

Verwijderd

Heb je niet de mogelijkheid om deze complexiteit op te delen in meerdere stored procedures? Wat je dan zou kunnen doen is meerdere procedures maken met hun eigen taak. Vanuit een andere procedure is het dan een kwestie van EXEC a, EXEC b, enzovoorts.

Het probleem wat jij noemt is dat je lang aan het zoeken bent naar de juiste plek binnen een enkele procedure.

Je zou ook door middel van comments keywords kunnen aanbrengen, zodat je met zoeken relatief eenvoudig naar de juiste locatie kan springen.

woensdag 4 juli 2007 06:33

Acties:

dusty

Celebrate Life!

Sloompie schreef op maandag 02 juli 2007 @ 07:53:
[..]
Zonder verdere details te kennen zit je volgens mij maar wat te blaten, of je hebt écht een glazen bol

Juist de volgende quote geeft in principe het probleem van het database design al aan:

Free rider schreef op maandag 02 juli 2007 @ 00:13:
[..] het gaat niet om een database, maar een stuk of dertig met dezelfde indeling. [..]

Als de enige reden is dat die databases gemaakt zijn voor security redenen, heeft de database designer/admin niet door dat er betere methodes zijn om security te implementeren ipv fysieke gescheiden databases te hebben.

Free rider schreef op maandag 02 juli 2007 @ 10:09:
[...]
Ik realiseer me dat vooral de eerste reden kort door de bocht is. Maar vooralsnog zie ik alleen dat je SP kan bewerken door een CREATE PROCEDURE statement te bewerken - niet erg vriendelijk volgens mij.

En een CREATE PROCEDURE is een stuk minder vriendelijk dan een CREATE FILE die je in principe doet als je je script "save/save as.." saved?

Free rider schreef op maandag 02 juli 2007 @ 10:26:
[...]
Ik hoop dat iemand naar voren komt die zelf een query van 10.000 regels heeft onderhouden en vertelt hoe hij ermee omgaat. Of een verwijzing naar een project met zo'n query.

Een query van 10.000 regels is gewoon niet onderhoudbaar. Als je een query hebt van 2 pagina's is dat al een uitzonderlijke grote query. Wat jij hebt is dan ook geen query van 10.000 regels, maar een script van 10.000 regels die verschillende queries uitvoerd.

Wil je zo'n grote script onderhoudbaar krijgen zul je in principe je script in kleinere sub-delen moeten opdelen. Waardoor er een betere overzicht te maken is welk queries wat doet, en wat er dus gebeurd in de set van queries in plaats van een grote script.

Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR

woensdag 4 juli 2007 06:40

Acties:

Verwijderd

Of je gooit het geheel gewoon in een applicatie gemaakt met [insert random programmeertaal]...

Wie maakt er nou een rapportage applicatie in losse SQL scripts...

woensdag 4 juli 2007 13:32

Acties:

woensdag 4 juli 2007 13:42

Topicstarter

Verwijderd schreef op woensdag 04 juli 2007 @ 06:40:
Of je gooit het geheel gewoon in een applicatie gemaakt met [insert random programmeertaal]...

Wie maakt er nou een rapportage applicatie in losse SQL scripts...

Nou ik maak dus zo'n applicatie. Eerst was het met een programmeertaal, die twintig queries liet uitvoeren, de resulterende records een voor een ophaalt, evalueert en een voor een in Excel plaatst. Een run duurt 30 tot 60 minuten.

In T-SQL duurt het 20 tot 30 seconden. NB de query werkt nooit met recordsets (niet nodig) en wordt daardoor veel efficienter dan een 'normale' programmeertaal die niet met verzamelingen om kan gaan.

Acties:

woensdag 4 juli 2007 14:18

Free rider schreef op woensdag 04 juli 2007 @ 13:32:
[...]

Nou ik maak dus zo'n applicatie. Eerst was het met een programmeertaal, die twintig queries liet uitvoeren, de resulterende records een voor een ophaalt, evalueert en een voor een in Excel plaatst. Een run duurt 30 tot 60 minuten.

In T-SQL duurt het 20 tot 30 seconden. NB de query werkt nooit met recordsets (niet nodig) en wordt daardoor veel efficienter dan een 'normale' programmeertaal die niet met verzamelingen om kan gaan.

als jij een query (of queries) in 20 seconden kan uitvoeren op een DB, dan kan een programma dat ook op diezelfde DB binnen ongeveer dezelfde tijd.

er is geen mogelijkheid dat je 30-60 minuten moet wachten (bij wat voor grote DB ook) op je data.
Wanneer dat zo is heb je echt een andere databasestructuur nodig waarin je wel goed gebruik maakt van indexen, en eventuele redundante data

This message was sent on 100% recyclable electrons.

Acties:

woensdag 4 juli 2007 14:24

Topicstarter

dusty schreef op woensdag 04 juli 2007 @ 06:33:
Als de enige reden is dat die databases gemaakt zijn voor security redenen, heeft de database designer/admin niet door dat er betere methodes zijn om security te implementeren ipv fysieke gescheiden databases te hebben.

De voornaamste reden is de klantperceptie. Nogmaals, ik vraag om ontwikkelingsadvies, geen beheers- of beveiligingsadvies. En ook niet om klantcommunicatie-advies, dus ik laat dit verder rusten.

Een query van 10.000 regels is gewoon niet onderhoudbaar. Als je een query hebt van 2 pagina's is dat al een uitzonderlijke grote query. Wat jij hebt is dan ook geen query van 10.000 regels, maar een script van 10.000 regels die verschillende queries uitvoerd.

Wil je zo'n grote script onderhoudbaar krijgen zul je in principe je script in kleinere sub-delen moeten opdelen. Waardoor er een betere overzicht te maken is welk queries wat doet, en wat er dus gebeurd in de set van queries in plaats van een grote script.

Het is niet zo dat de verschillende queries los van elkaar staan. Er zijn tussenresultaten in variabelen en tabelvariabelen, welke meerdere keren worden gebruikt. Er zijn afhankelijkheden tussen de onderdelen.

De constatering dat een script van een beetje afmeting niet kan worden gebruikt in onderhoudbare software is... intrigerend. Heb je toevallig links naar artikelen die dit onderschrijven?

Acties:

woensdag 4 juli 2007 14:29

Free rider schreef op woensdag 04 juli 2007 @ 14:18:
De constatering dat een script van een beetje afmeting niet kan worden gebruikt in onderhoudbare software is... intrigerend. Heb je toevallig links naar artikelen die dit onderschrijven?

daar mag je eens op googlen, is wel erg veel over te vinden.
Maar buiten dat, stel je voor, je komt te werken in het bedrijf waar jij werkt.

Er staat een foutje in dat script, laten we zeggen dat bij een insert in een bepaalde tabel data afgekapt wordt.
Hoe hard vraag jij je ontslag aan op het moment dat je voor een fout als dat 10.000 regels code voor je neus krijgt?

[ Voor 4% gewijzigd door BasieP op 04-07-2007 14:26 ]

This message was sent on 100% recyclable electrons.

Acties:

woensdag 4 juli 2007 14:43

Topicstarter

BasieP schreef op woensdag 04 juli 2007 @ 13:42:
als jij een query (of queries) in 20 seconden kan uitvoeren op een DB, dan kan een programma dat ook op diezelfde DB binnen ongeveer dezelfde tijd.

Ik gebruik C#, en deze taal heeft geen mogelijkheid tot het manipuleren van verzamelingen. De enige mogelijkheid is het doorlopen van alle records, een voor een. In SQL kan je met hele tabellen aan de slag.

er is geen mogelijkheid dat je 30-60 minuten moet wachten (bij wat voor grote DB ook) op je data.
Wanneer dat zo is heb je echt een andere databasestructuur nodig waarin je wel goed gebruik maakt van indexen, en eventuele redundante data

Je wacht niet op de DB maar op het ophalen van de data, en het doorlopen van de records, en het wegschrijven - een voor een - van de resultaten.

In mijn optiek is een SQL Database server vooral ontworpen voor de manipulatie van data, dus waarom zou ik de mogelijkheden niet benutten?

Acties:

woensdag 4 juli 2007 14:44

Topicstarter

BasieP schreef op woensdag 04 juli 2007 @ 14:24:
[...]
daar mag je eens op googlen, is wel erg veel over te vinden.
Maar buiten dat, stel je voor, je komt te werken in het bedrijf waar jij werkt.

Er staat een foutje in dat script, laten we zeggen dat bij een insert in een bepaalde tabel data afgekapt wordt.
Hoe hard vraag jij je ontslag aan op het moment dat je voor een fout als dat 10.000 regels code voor je neus krijgt?

Heb je een wat explicietere link, want ik kan maar niet ontdekken dat SQL niet onderhoudbaar is en (bijv) nooit gebruikt mag worden in software die kritische operaties uitvoert.

En ja, ik heb gewerkt aan software van miljoenen regels, en ik kan verklappen dat daar honderden fouten in stonden. Niemand vroeg ontslag en niemand werd ontslagen. Sterker nog, iedereen was erg tevreden omdat de software zo stabiel en betrouwbaar was.

Acties:

Creepy

Tactical Espionage Splatterer

Even voor mezelf samenvattend: Je hebt een brei code van meer dan 1000 regels en dat wil je onderhouden. That's it?

Opsplitsen in logische stukken is echt het enige dat je kan doen.

Het volgende uiteraard nofi en is echt serieus bedoeld:

Je vind het normaal om enorme lappen code te hebben? Dat de onderhoudbaarheid slecht is merk je nu zelf ook dus waarom zou je het niet gaan opsplitsen in logische delen? Je hebt aan mij een hele slechte als je als collega van mij een oplossing zoals deze zou presenteren.

Ik gok dat de traagheid van de vorige oplossing prima op te lossen is zonder dat je een brei aan code direct naar de DB moet pompen. Ik kan me niet voorstellen dat je in C# niet de mogelijkheid hebt om in-memory tabellen aan te maken en hierop bewerkingen uit te voeren, dat is namelijk wat je nu op de SQL server doet.

En laat dat opschepperige voortaan aub gewoon weg. Het voegt niks toe aan de discussie en wekt alleen maar irritatie op.

[ Voor 75% gewijzigd door Creepy op 04-07-2007 15:02 ]

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

woensdag 4 juli 2007 14:48

Acties:

woensdag 4 juli 2007 14:53

Topicstarter

Verwijderd schreef op maandag 02 juli 2007 @ 10:43:
[...]
Ja ze zijn wat lastiger te beheren, maar je hebt er al voor gekozen om de logica in sql uit te voeren door immense queries te bouwen. Dus waarom die immense queries niet wat versimpelen vaste patronen onder te brengen in SPs? Je kunt SPs zo schrijven dat je ze nauwelijks hoeft te beheren, denk hierbij aan het gebruik van '%rowtype' als argument i.p.v. specifieke velden. Ik denk dus dat je je ook niet teveel moet focussen op de beheersbaarheid. Het is altijd die gulde middenweg waar je een beetje doorheen moet zien te schipperen.

Heb je wat voorbeelden van dit soort SPs? Ik heb wat gebladerd in de standaard SQL Server queries maar vond niets.

Acties:

woensdag 4 juli 2007 15:18

Free rider schreef op woensdag 04 juli 2007 @ 14:43:
[...]

Heb je een wat explicietere link, want ik kan maar niet ontdekken dat SQL niet onderhoudbaar is en (bijv) nooit gebruikt mag worden in software die kritische operaties uitvoert.

Ik heb nooit gezegt dat sql niet onderhoudbaar is, en dat het niet gebruikt mag worden voor kritieke operaties. hier ga ik dus ook niet voor je naar zoeken, dat doe je maar lekker zelf.

Wat ik wel weet is dat SQL een QUERY language is, en dat dit niet bedoeld is als platform om op te programmeren.
Dat het wel KAN wil nog niet zeggen dat het verstandig is.

verder sluit ik me aan bij Creepy, ik kan me niet voorstellen dat .net niet dezelfde functionaliteit kan bieden die jij nu in SQL Server gebruikt.

This message was sent on 100% recyclable electrons.

Acties:

woensdag 4 juli 2007 15:32

Topicstarter

Creepy schreef op woensdag 04 juli 2007 @ 14:44:
Even voor mezelf samenvattend: Je hebt een brei code van meer dan 1000 regels en dat wil je onderhouden. That's it?

Opsplitsen in logische stukken is echt het enige dat je kan doen.

Het volgende uiteraard nofi en is echt serieus bedoeld:

Je vind het normaal om enorme lappen code te hebben? Dat de onderhoudbaarheid slecht is merk je nu zelf ook dus waarom zou je het niet gaan opsplitsen in logische delen? Ik gok dat de traagheid van de vorige oplossing prima op te lossen is zonder dat je een brei aan code direct naar de DB moet pompen. Ik kan me niet voorstellen dat je in C# niet de mogelijkheid hebt om in memory tabellen aan te maken en hierop bewerkingen uit te voeren, dat is namelijk wat je nu op de SQL server doet.

Samenvatting klopt, maar dit is mijn kleinste project tot nu toe: het is voor eerst sinds jaren een project met minder dan 50.000 regels. Maar nu is het voornamelijk T-SQL, en ik twijfel hoe lang het nog onderhoudbaar blijft.
Ik weet ook dat ik de code moet splitsen, maar de vraag is hoe. Binnen C# kan ik gebruik maken van methods, classes, namespaces, source files, assemblies enz. In T-SQL heb ik alleen SPs.

Als ik alternatieven voor T-SQL overweeg, dan hoogstens OLAP of SSIS - maar geen 'gewone' programmeertaal waarbij de records een voor een opgehaald en verwerkt moeten worden.

Acties:

woensdag 4 juli 2007 15:40

Topicstarter

BasieP schreef op woensdag 04 juli 2007 @ 14:53:
[...]
verder sluit ik me aan bij Creepy, ik kan me niet voorstellen dat .net niet dezelfde functionaliteit kan bieden die jij nu in SQL Server gebruikt.

Ik sluit me hierbij aan - C# heeft eerder meer dan minder functionaliteit.

De reden dat ik voor T-SQL kies is de performance. De query parser directe toegang tot de storage engine en zal waarschijnlijk niet nalaten om hier gebruik van te maken. Verder werkt T-SQL met verzamelingen en kan hier fijn naar optimaliseren, terwijl ik in C# alleen maar foreach() loopjes kan gebruiken. Dat laatste wordt met LINQ wellicht anders, maar daar heb ik nu niets aan.

Acties:

woensdag 4 juli 2007 15:44

Free rider schreef op woensdag 04 juli 2007 @ 15:32:
[...]

Ik sluit me hierbij aan - C# heeft eerder meer dan minder functionaliteit.

De reden dat ik voor T-SQL kies is de performance. De query parser directe toegang tot de storage engine en zal waarschijnlijk niet nalaten om hier gebruik van te maken. Verder werkt T-SQL met verzamelingen en kan hier fijn naar optimaliseren, terwijl ik in C# alleen maar foreach() loopjes kan gebruiken. Dat laatste wordt met LINQ wellicht anders, maar daar heb ik nu niets aan.

nogmaals: is dat wel zo?
ik heb het nooit gedaan, maar kan je in .net niet gewoon complete datasets veranderen met 1 commando?

This message was sent on 100% recyclable electrons.

Acties:

woensdag 4 juli 2007 15:47

Free rider schreef op woensdag 04 juli 2007 @ 15:32:
[...]

Ik sluit me hierbij aan - C# heeft eerder meer dan minder functionaliteit.

De reden dat ik voor T-SQL kies is de performance. De query parser directe toegang tot de storage engine en zal waarschijnlijk niet nalaten om hier gebruik van te maken. Verder werkt T-SQL met verzamelingen en kan hier fijn naar optimaliseren, terwijl ik in C# alleen maar foreach() loopjes kan gebruiken. Dat laatste wordt met LINQ wellicht anders, maar daar heb ik nu niets aan.

Je kan toch ook mbhv SQL een hele set van gegevens inladen in een typed dataset bv in een C# programma. Dan kan je daar ook met Select Expressies enzo gaan werken.

https://fgheysels.github.io/

Acties:

woensdag 4 juli 2007 18:33

Mja, als je setbased operaties op grote hoeveelheden data moet verrichten is een SQL-dialect een betere keus dan C#, denk ik.

Oops! Google Chrome could not find www.rijks%20museum.nl

Acties:

Verwijderd

Je kunt met C# gewoon queries uitvoeren hoor, als je het dus met een SQL script kon moet je het sowieso met C# kunnen al is het maar dat je gewoon de queries een voor een uitvoert.

Het verschil is dan dat je eenvoudig alles kunt gaan opdelen in C# en waar nodig dingen niet met SQL te doen maar puur in C#, dit kan je een flinke tijdswinst opleveren. C# is een enorm krachtige taal, vele malen krachtiger als puur SQL.

Je kunt je applicatie dus relatief eenvoudig omzetten naar C# en daar geen performanceverlies bij hebben. De voordelen die je dan wel hebt is dat je de boel beheersbaar maakt en waar nodig zaken in de krachtigere C# taal doet waar je een flinke tijdswinst mee kunt behalen.

En zoals gezegd: Laat dat opschepperige nu eens weg, het is (imho) overduidelijk dat je gewoon compleet uit je nek lult want als dit echt een kleiner project zou zijn als je normaal mee werkt zou dit allemaal geen enkel probleem moeten zijn.

Ik zou mezelf niet eens een professional willen noemen als ik zou werken met SQL scripts van 50.000 regels, dan doe je gewoon echt iets niet goed.

woensdag 4 juli 2007 19:09

Acties:

woensdag 4 juli 2007 19:32

Verwijderd schreef op woensdag 04 juli 2007 @ 18:33:

Het verschil is dan dat je eenvoudig alles kunt gaan opdelen in C# en waar nodig dingen niet met SQL te doen maar puur in C#, dit kan je een flinke tijdswinst opleveren. C# is een enorm krachtige taal, vele malen krachtiger als puur SQL.

Dat is wel heel kort door de bocht.
Zoals P_de_B al zegt: als het vooral om set-gerelateerde logica gaat, dan is SQL duizend keer performanter dan C#; SQL is nl. een DSL specifiek voor deze problematiek.

Je kunt je applicatie dus relatief eenvoudig omzetten naar C# en daar geen performanceverlies bij hebben.

Nogmaals, dat kan je wel. Zowiezo weet jij niet wat die applicatie van de TS precies doet.

https://fgheysels.github.io/

Acties:

woensdag 4 juli 2007 20:16

Verwijderd schreef op woensdag 04 juli 2007 @ 18:33:
C# is een enorm krachtige taal, vele malen krachtiger als puur SQL.

Dat is echt grote onzin. Je moet de juiste tool voor de juiste job gebruiken. Als je op grote hoeveelheden data in een database operaties moet uitvoeren moet je geen C# gebruiken, maar SQL. De ene taal is niet krachtiger dan de andere, beide talen zijn voor hele verschillende zaken gemaakt.

[ Voor 0% gewijzigd door P_de_B op 04-07-2007 19:33 . Reden: wat wiebenik zegt dus ]

Oops! Google Chrome could not find www.rijks%20museum.nl

Acties:

woensdag 4 juli 2007 20:21

Topicstarter

De verlangde functionaliteit is ook mogelijk met C#, de applicatie werkte zo totdat ik het op mijn bord kreeg. Deze applicatie deed duizenden queries, op basis van de ene query werden per geretourneerd record nieuwe queries uitgevoerd, die resultaten gaven soms ook weer nieuwe queries.
Deze applicatie was te langzaam.
Een gangbare optimalizatie is het combineren van queries in een batch, en deze in een keer aan te bieden. Dat is wat ik deed: ik implementeerde alle logica in T-SQL en de applicatie werd 100 keer zo snel. De applicatie werkt naar ieders tevredenheid, maar ik voorzie onderhouds- en overdrachtsproblemen als ik niets doe aan de project-opzet.

Ik vind het alleen vreemd dat er enerzijds gesteld wordt dat je voor een betere performance queries moet combineren, en anderzijds dat mensen die inderdaad gaan combineren verkeerd bezig zijn. Dat laatste is niet alleen de mening van andere schrijvers in dit topic, maar ook mijn constatering.

PS
De enige reden dat ik mijn ervaring heb genoemd is dat ik de indruk wil wegnemen dat ik niet weet waar ik mee bezig ben. Ik realiseer me nu dat het arrogant klinkt - bij deze mijn welgemeende excuses.

Acties:

Verwijderd

P_de_B schreef op woensdag 04 juli 2007 @ 19:32:
[...]

Dat is echt grote onzin. Je moet de juiste tool voor de juiste job gebruiken. Als je op grote hoeveelheden data in een database operaties moet uitvoeren moet je geen C# gebruiken, maar SQL. De ene taal is niet krachtiger dan de andere, beide talen zijn voor hele verschillende zaken gemaakt.

Leg eens uit dan hoe een SQL script invoeren anders is als met C# de hele lading queries achter elkaar uitvoeren? De data hoef je toch niet terug naar C# te laten gaan of daar iets mee te doen, je kunt dat nog steeds allemaal door de SQL server laten doen.

Wel heb je de mogelijkheid de boel logisch te splitsen en daar waar nodig of handig de stukken van het SQL script te vervangen door puur C# of een combo van C# en SQL.

C# is als taal veel krachtiger dan puur SQL, dat er situaties zijn waarbij puur SQL een betere performance geeft heeft natuurlijk niets te maken met de kracht van een taal.

woensdag 4 juli 2007 20:23

Acties:

woensdag 4 juli 2007 20:27

Free rider schreef op woensdag 04 juli 2007 @ 20:16:
De verlangde functionaliteit is ook mogelijk met C#, de applicatie werkte zo totdat ik het op mijn bord kreeg. Deze applicatie deed duizenden queries, op basis van de ene query werden per geretourneerd record nieuwe queries uitgevoerd, die resultaten gaven soms ook weer nieuwe queries.
Deze applicatie was te langzaam.
Een gangbare optimalizatie is het combineren van queries in een batch, en deze in een keer aan te bieden. Dat is wat ik deed: ik implementeerde alle logica in T-SQL en de applicatie werd 100 keer zo snel. De applicatie werkt naar ieders tevredenheid, maar ik voorzie onderhouds- en overdrachtsproblemen als ik niets doe aan de project-opzet.

Ik vind het alleen vreemd dat er enerzijds gesteld wordt dat je voor een betere performance queries moet combineren, en anderzijds dat mensen die inderdaad gaan combineren verkeerd bezig zijn. Dat laatste is niet alleen de mening van andere schrijvers in dit topic, maar ook mijn constatering.

PS
De enige reden dat ik mijn ervaring heb genoemd is dat ik de indruk wil wegnemen dat ik niet weet waar ik mee bezig ben. Ik realiseer me nu dat het arrogant klinkt - bij deze mijn welgemeende excuses.

Helemaal afhankelijk van je queries, wensen en data kun je best voor een T-SQL oplossing kiezen. Dat hoeft echter niet te betekenen dat het in een query van duizenden regels hoeft. Je kunt bijvoorbeeld functies, views en stored procedures gebruiken om gedeeltes van de oorspronkelijke grote query onder te verdelen.

Zoals je al beschreef kan een applicatie die veel data moet selecteren of manipuleren vele malen sneller worden als je een set based oplossing met SQL maakt, als dat bij jou ook zo is kun je prima bij je SQL oplossing blijven zou ik zeggen, breng er alleen wat structuur in aan zou ik zeggen.

[ Voor 51% gewijzigd door P_de_B op 04-07-2007 20:28 . Reden: quote toegevoegd ]

Oops! Google Chrome could not find www.rijks%20museum.nl

Acties:

woensdag 4 juli 2007 22:03

Verwijderd schreef op woensdag 04 juli 2007 @ 20:21:
[...]

Leg eens uit dan hoe een SQL script invoeren anders is als met C# de hele lading queries achter elkaar uitvoeren? De data hoef je toch niet terug naar C# te laten gaan of daar iets mee te doen, je kunt dat nog steeds allemaal door de SQL server laten doen.

¨
Ik heb genoeg applicaties gezien die gegevens ophaalden en op basis van die dataset nieuwe queries gingen uitvoeren. Honderden connecties naar de server zijn echt niet goed voor je performance.

Wel heb je de mogelijkheid de boel logisch te splitsen en daar waar nodig of handig de stukken van het SQL script te vervangen door puur C# of een combo van C# en SQL.

Dat klopt, dat kan heel goed. Je moet er alleen voor zorgen dat je de operaties op de data met SQL blijft doen imo

C# is als taal veel krachtiger dan puur SQL, dat er situaties zijn waarbij puur SQL een betere performance geeft heeft natuurlijk niets te maken met de kracht van een taal.

Nogmaals, dat is onzin. Een hamer is ook niet beter dan een beitel. Soms heb je een hamer nodig, soms een beitel. Dat is echt precies hetzelfde als C# vs. SQL. Ik hoef hopelijk niet uit te leggen dat bewerkingen op grote hoeveelheden data niet echt goed gaan werken met C#.

Oops! Google Chrome could not find www.rijks%20museum.nl

Acties:

woensdag 4 juli 2007 22:45

Topicstarter

P_de_B schreef op woensdag 04 juli 2007 @ 20:23:
Zoals je al beschreef kan een applicatie die veel data moet selecteren of manipuleren vele malen sneller worden als je een set based oplossing met SQL maakt, als dat bij jou ook zo is kun je prima bij je SQL oplossing blijven zou ik zeggen, breng er alleen wat structuur in aan zou ik zeggen.

De beslissing voor T-SQL veroorzaakte een enorme performance-winst, waardoor allemaal nieuwe wensen ontstaan. Het honoreren van deze wensen zal vooral leiden tot een hogere complexiteit van de gehele applicatie. Ik ben dat soort problemer liever voor dus onderzoek ik de structurerings-mogelijkheden.

Bij andere talen is het meestal mogelijk om functionaliteit en implementaties te isoleren en abstraheren. Ik denk aan interfaces, classes met private/protected members, lokale variabelen enz.
Binnen SQL heb je SPs, Functions en Views. Maar deze middelen hebben weer een bereik over de query heen - ze worden onderdeel van de database. De isolatie ontbreekt, daardoor ben ik geneigd te denken dat er nog andere mogelijkheden zijn.

Acties:

donderdag 5 juli 2007 03:23

Als de data zo veel is, en uit verschillende bronnen komt, kun je dan niet overwegen een datawarehouse te maken. Het voert te ver dat even in een post uit te leggen, maar Google eens op datawarehousing en olap cubes.

Met een olap cube maak een een meerdimensionale 'verzameling'van grote hoeveelheden gegevens. Van deze verzameling kun je dan eenvoudig allerlei verschillende dwarsdoorsnedes maken. Je richt een nieuwe database in als datawarehouse, waarin gegevens van verschillende systemen opgeslagen en geanalyseerd kunnen worden.

Oops! Google Chrome could not find www.rijks%20museum.nl

Acties:

dusty

Celebrate Life!

Free rider schreef op woensdag 04 juli 2007 @ 14:18:
[...]
Het is niet zo dat de verschillende queries los van elkaar staan. Er zijn tussenresultaten in variabelen en tabelvariabelen, welke meerdere keren worden gebruikt. Er zijn afhankelijkheden tussen de onderdelen.

De constatering dat een script van een beetje afmeting niet kan worden gebruikt in onderhoudbare software is... intrigerend. Heb je toevallig links naar artikelen die dit onderschrijven?

Daar heb ik een mooie vraag op terug waarop je zelf antwoord kunt geven:

Free rider schreef op woensdag 04 juli 2007 @ 14:43:
[...]
En ja, ik heb gewerkt aan software van miljoenen regels, en ik kan verklappen dat daar honderden fouten in stonden.
[...]

Bestond dat programma uit functies gebouwd van 10.000 regels per stuk?

Ik gok en vermoed dat je hierop "Nee." zegt. De vraag daarna is uiteraard, Waarom daarbij niet en opeens in SQL wel?

Binnen het programma horen dingen ook bij elkaar en zijn ze ook afhankelijk maar je stopt ze daarbij ook niet binnen dezelfde functie? Juist de redenen waarom je het bij een programma niet doet gelden ook waarom je het niet in dezelfde 'functie' moet stoppen binnen SQL.

Verwijderd schreef op woensdag 04 juli 2007 @ 20:21:
[...]
C# is als taal veel krachtiger dan puur SQL, dat er situaties zijn waarbij puur SQL een betere performance geeft heeft natuurlijk niets te maken met de kracht van een taal.

Zodra je met reporting systemen gaat werken, heb je kans dat je reports zo groot worden dat het onwijs is om de records eerst naar je 'programmeer' taal te halen om daarop weer nieuwe records uit te voeren, vooral als er meerdere clients tegelijk in gebruik zijn. Juist daarbij is het slimmer om je reporting logica uit te voeren als een script. Met 'script' bedoel ik dan ook dat je dan een SP aanroept, waarbij je binnen je sessie blijft en de data netjes wordt gefixed binnen de database waarbij het uiteraard mogelijk is dat deze SP weer andere SP's aanroept, dit zonder dat er constant informatie van de client naar de database en terug gestuurd moet worden.

Juist voor reporting systemen zou ik persoonlijk ook aanraden om de logica binnen (T-)SQL op te lossen, En juist niet in een programmeertaal (zoals C#).

Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR

donderdag 5 juli 2007 07:53

Acties:

Confusion

Fallen from grace

Free rider schreef op woensdag 04 juli 2007 @ 14:18:
De constatering dat een script van een beetje afmeting niet kan worden gebruikt in onderhoudbare software is... intrigerend. Heb je toevallig links naar artikelen die dit onderschrijven?

Geen artikel, wel een boek: Code Complete 2. Maar je hebt er geen artikel voor nodig: kleine stukken code, met een betekenisvolle methodenaam, waarvan je de werking snel kan overzien als je de code aan het volgen bent, zorgen voor veel onderhoudbaardere code. McConnell geeft in zijn boek diverse cijfers waarmee ook die bewering wordt onderbouwd, maar wat mij betreft is het plain obvious. Het scheelt gewoon zoekwerk: lange methods moet je telkens opnieuw compleet doorlezen om te zien wat er gebeurt. Van korte stukken met betekenisvolle namen kan je in een oogopslag evalueren of je de code zelf nog moet gaan bekijken.

Wie trösten wir uns, die Mörder aller Mörder?

donderdag 5 juli 2007 09:06

Acties:

barfieldmv

Confusion schreef op donderdag 05 juli 2007 @ 07:53:
[...]
kleine stukken code, met een betekenisvolle methodenaam, waarvan je de werking snel kan overzien als je de code aan het volgen bent

Ik zou de code indien mogelijk verspreiden over losse Stored Procedures met een vaste naam. Deze stored procedures zou ik zo proberen te maken dat ze zo onafhankelijk mogelijk van elkaar werken. De stored procedures zou ik ook logisch over de databases verspreiden.

Een andere optie is om de code per database te verspreiden zodat zoveel mogelijk lokale logica op de server blijft staan.

Als laatste optie is het maken van veel uitleg en een uitgebreide documentatie die gericht is op het aanpassen van de god-stored procedure een optie.

Mijn ervaring is het gebruik en aanpassen van één enkel 2000 regels sql bestand. Slecht aan te passen en lastig in onderdelen op te breken. Gelukkig is er meestal een gedeelte dat altijd aangepast moet worden en de rest redelijk constant

Ik geloof dat ik een dag bezig was met het begrijpen van de stored procedure en dat was zonder sql kennis (dag per 2000 regels +db model)

[ Voor 19% gewijzigd door barfieldmv op 05-07-2007 09:08 ]

donderdag 5 juli 2007 10:01

Acties:

joepP

Zit je niet gewoon met het klassieke probleem van het complexe domein?

Ik vermoed dat een nette procesbeschrijving van de gewenste rapportage ook heel lang zal zijn, en heel weinig overlap zal bevatten. Als de vorm van je proces sequentieel is, en ook nog lang, dan zal je code dat ook al snel worden. Heel veel beter dan alle losse stappen in een SP proppen, en die achter elkaar aanroepen vanuit een overkoepelende SP zal het dus niet worden. Het is zelfs maar de vraag of je daarmee een beter leesbaar/onderhoudbaar geheel overhoudt, ik vrees eigenlijk van niet.

Iets beters dan de boel zeer duidelijk documenteren zie ik eigenlijk niet.

donderdag 5 juli 2007 12:22

Acties:

Niemand_Anders

Dat was ik niet..

Volgens mij had ik in eerdere reacties gelezen dat het hier gaat om een sql 2005 database. Klopt dit? Want dan zou je gewoon in C# stored procedures schrijven die direct op de database worden uitgevoerd.

Daarnaast klinkt het importeren van een excel in een database heel erg als een 'Integration service' project welke zeer eenvoudig met Business Development Studio welke geleverd wordt met sql 2005 en dan kun je ook een flow aangeven hoe een fout moet worden afgehandeld. Een Integration Service project is eigenlijk een DTS (sql 2000) package op steroïden.

If it isn't broken, fix it until it is..

donderdag 5 juli 2007 17:54

Acties:

donderdag 5 juli 2007 18:00

Topicstarter

Confusion schreef op donderdag 05 juli 2007 @ 07:53:
[...]

Geen artikel, wel een boek: Code Complete 2. Maar je hebt er geen artikel voor nodig: kleine stukken code, met een betekenisvolle methodenaam, waarvan je de werking snel kan overzien als je de code aan het volgen bent, zorgen voor veel onderhoudbaardere code. McConnell geeft in zijn boek diverse cijfers waarmee ook die bewering wordt onderbouwd, maar wat mij betreft is het plain obvious. Het scheelt gewoon zoekwerk: lange methods moet je telkens opnieuw compleet doorlezen om te zien wat er gebeurt. Van korte stukken met betekenisvolle namen kan je in een oogopslag evalueren of je de code zelf nog moet gaan bekijken.

Ik ken het boek, maar dank dat je mij er weer op wijst. De meeste principes gebruik ik in andere programmeertalen, ik heb bv. (bijna) nooit methods van meer dan 40 regels, de meeste methods zijn private danwel protected enz.
Maar als ik met SQL een SP maak, wordt deze zichtbaar in de hele database. Nu zal deze ene applicatie verantwoordelijk zijn voor (zeg) 50 SPs, waar andere applicaties waarschijnlijk niets aan hebben. Daardoor kan een namespace probleem ontstaan, de naam van de SP moet immers uniek zijn en kan dus niet meer door andere applicaties gedefinieerd worden.

Ik weet vrij zeker dat McConnell het principe van isolatie / beperkt bereik in Code Complete behandeld. Maar met SQL lijkt het niet goed mogelijk.

Maar ik zal Code Complete er eens bijhalen (is uitgeleend!!). Dank.

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Free rider schreef op donderdag 05 juli 2007 @ 17:54:
Nu zal deze ene applicatie verantwoordelijk zijn voor (zeg) 50 SPs, waar andere applicaties waarschijnlijk niets aan hebben. Daardoor kan een namespace probleem ontstaan, de naam van de SP moet immers uniek zijn en kan dus niet meer door andere applicaties gedefinieerd worden.

Dan prefix je de SP's met 'myreportingapp_' ofzo? Als dat de enige reden is waarom je geen SP's wil gebruiken... Daarnaast kun je op user niveau de execute rechten e.d. instellen voor een SP (en volgens mij, maar daar ben ik niet zeker van, kun je SP's ook nog verbergen voor mensen die er niets mee te maken hebben...alsof 'reguliere gebruikers' uberhaupt al SP's te zien zouden krijgen ...)

[ Voor 21% gewijzigd door RobIII op 05-07-2007 18:03 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

donderdag 5 juli 2007 18:07

Acties:

donderdag 5 juli 2007 18:22

Topicstarter

barfieldmv schreef op donderdag 05 juli 2007 @ 09:06:
[...]
Ik zou de code indien mogelijk verspreiden over losse Stored Procedures met een vaste naam. Deze stored procedures zou ik zo proberen te maken dat ze zo onafhankelijk mogelijk van elkaar werken. De stored procedures zou ik ook logisch over de databases verspreiden.

Een andere optie is om de code per database te verspreiden zodat zoveel mogelijk lokale logica op de server blijft staan.

Als laatste optie is het maken van veel uitleg en een uitgebreide documentatie die gericht is op het aanpassen van de god-stored procedure een optie.

Mijn ervaring is het gebruik en aanpassen van één enkel 2000 regels sql bestand. Slecht aan te passen en lastig in onderdelen op te breken. Gelukkig is er meestal een gedeelte dat altijd aangepast moet worden en de rest redelijk constant

Ik geloof dat ik een dag bezig was met het begrijpen van de stored procedure en dat was zonder sql kennis (dag per 2000 regels +db model)

Ik ben zowaar niet de enige.
Ik lees tussen de regels dat je het liefste de eerste oplossing had gekozen, maar dat dat nog niet gelukt is, en dat de bestaande oplossing vooralsnog werkbaar is. Toch?

Acties:

donderdag 5 juli 2007 20:57

Topicstarter

Niemand_Anders schreef op donderdag 05 juli 2007 @ 12:22:
Daarnaast klinkt het importeren van een excel in een database heel erg als een 'Integration service' project welke zeer eenvoudig met Business Development Studio welke geleverd wordt met sql 2005 en dan kun je ook een flow aangeven hoe een fout moet worden afgehandeld. Een Integration Service project is eigenlijk een DTS (sql 2000) package op steroïden.

Het project is precies andersom, uit een database wordt een Excel bestandje gemaakt. SSIS is een van de alternatieven die ik overweeg (OLAP is de andere) als SQL niet geschikt blijkt voor grotere projecten.

Acties:

Confusion

Fallen from grace

Free rider schreef op donderdag 05 juli 2007 @ 17:54:
Ik ken het boek, maar dank dat je mij er weer op wijst. De meeste principes gebruik ik in andere programmeertalen, ik heb bv. (bijna) nooit methods van meer dan 40 regels, de meeste methods zijn private danwel protected enz.

Dan begrijp ik niet waarom je de opmerking die ik citeerde maakte.

Maar als ik met SQL een SP maak, wordt deze zichtbaar in de hele database. Nu zal deze ene applicatie verantwoordelijk zijn voor (zeg) 50 SPs, waar andere applicaties waarschijnlijk niets aan hebben. Daardoor kan een namespace probleem ontstaan, de naam van de SP moet immers uniek zijn en kan dus niet meer door andere applicaties gedefinieerd worden.

Ik ken SQL Server niet, maar het lijkt me dat het fatsoenlijke mogelijkheden biedt om het gebruik en domein van SP's te reguleren. Op zijn minst doordat je execute rechten moet toewijzen voor iemand een SP uit mag voeren, maar vast ook doordat je de SP aan een tablespace of iets soortgelijks kan verbinden. Dan wordt het toch allemaal een stuk overzichtelijker en beter te handhaven?

Wie trösten wir uns, die Mörder aller Mörder?

donderdag 5 juli 2007 21:02

Acties:

donderdag 5 juli 2007 21:45

TS: met schema's kun je stored procs 'scheiden', zie: http://msdn2.microsoft.com/en-us/library/ms190387.aspx

Oops! Google Chrome could not find www.rijks%20museum.nl

Acties:

donderdag 5 juli 2007 22:08

Topicstarter

P_de_B schreef op donderdag 05 juli 2007 @ 21:02:
TS: met schema's kun je stored procs 'scheiden', zie: http://msdn2.microsoft.com/en-us/library/ms190387.aspx

... En dat is het idee wat ik zocht. Duizend maal dank!

Acties:

donderdag 5 juli 2007 22:26

Topicstarter

Confusion schreef op donderdag 05 juli 2007 @ 20:57:
Ik ken SQL Server niet, maar het lijkt me dat het fatsoenlijke mogelijkheden biedt om het gebruik en domein van SP's te reguleren. Op zijn minst doordat je execute rechten moet toewijzen voor iemand een SP uit mag voeren, maar vast ook doordat je de SP aan een tablespace of iets soortgelijks kan verbinden. Dan wordt het toch allemaal een stuk overzichtelijker en beter te handhaven?

Inderdaad, P_de_B kwam hier ook mee...
Het idee om de isolatie te realiseren met security is de oplossing. Ik zou er nooit op zijn gekomen, ik kon mij alleen een oplossing binnen de taal voorstellen.

Tijd voor een cursus 'thinking outside the box'.

Acties:

tss68nl

Free rider schreef op donderdag 05 juli 2007 @ 18:22:
[...]
Het project is precies andersom, uit een database wordt een Excel bestandje gemaakt. SSIS is een van de alternatieven die ik overweeg (OLAP is de andere) als SQL niet geschikt blijkt voor grotere projecten.

Watte? Hihi...kuch

SQL niet geschikt voor grotere projecten? SQL is geschikt voor de grootste projecten die je je maar kan indenken. Einde discussie.

C# sneller dan SQL? SQL is vele malen beter in het bewerken van grote hoeveelheden data.

SSIS als alternatief? Leuke tool voor ETL, maar pure databehandeling is nog steeds sneller in SQL middels views of stored procedures.

OLAP als alternatief voor SQL? Ik ben je even kwijt, dat kan helemaal niet.

KNX Huisautomatisering - DMX Lichtsturing

vrijdag 6 juli 2007 08:51

Acties: