[Java/SQL Server] Java Threads of DTS packages + s

[zneek]

Ik ben bezig een redelijk grote applicatie te bouwen. Ik moet gegevens afkomstig uit een extern systeem importeren en converteren. De bestanden zijn .CSV en moeten in SQL SERVER terecht komen.

Nu twijfel ik over 2 opties:

1. Java
Het importeren en converteren van de gegevens in een Java thread stoppen. Deze zal op een aparte applicatieserver komen te draaien, en zal via het netwerk de CSV files en de SQL Server moeten bereiken.

2. DTS + stored procedures
Het importeren in een DTS package stoppen, die gebruik maakt van stored procedures die de conversie doen. De CSV files zullen via het netwerk opgehaald moeten worden.

Ik vraag me af in hoeverre ik in SQL Server genoeg mogelijkheden heb voor de conversie. Daarnaast ben ik geen Transact-SQL tovenaar . Daar zal ik dus nog e.e.a. van moeten leren. In Java heb ik genoeg ervaring mee om alle logica mee te kunnen bouwen. Maar, DTS packages kun je standaard schedulen, voor de Java thread oplossing zal ik zelf een scheduler moeten schrijven.

Ideeen?? Tips? Hints? Tricks?

[Alarmnummer]

Ik kan je helaas alleen wat advies geven op java gebied, want ik heb zelf nog nooit iets gedaan met stored procedures ed. Het is wel vrij vervelend dat je inderdaad een andere machine moet gebruiken om java op te zetten ipv dat alles in de db gaat. Maar een scheduler schrijven hoeft niet zo`n probleem te zijn. Je kan gebruik maken van de Timer class (die je in kan stellen zoals je maar wilt) en daarmee ben je met het schedulen klaar. Verder denk ik dat een applicatie server een beetje overkill is hiervoor tenzij je ook iets met EJB wilt doen. Je kan gewoon een klein server programma op een computer laten draaien en that`s it.

[Bobco]

Als het converteren moeilijker is dan veld 1 -> kolom 1 enzvoorts, dan zou ik geneigd zijn een Java-only oplossing te kiezen. Als de Schedule eisen niet ingewikkelder zijn dan een per x seconden kijken of er files staan die geimporteerd moeten worden, dan is dat uitermate simpel te regelen met een aparte Java-thread die niets anders doet dan slapen en om de x seconden kijken of er een file is. Is die er dan kan er een verwerkings-thread gestart worden.

Het belangrijkste criterium is denk ik de ingewikkeldheid van de conversie. Als je dingen wilt zoals echte validatie van gegevens, conditionele conversie enz dan zou ik de flexibiliteit van Java gebruiken.

Een ander punt van overweging is misschien de scheiding van de taken. Als een DTS package de file moet kunnen zien, dan betekent dat ook dat die file bereikbaar moet zijn via het filesysteem van de machine waarop SQL Server draait. In de Java oplossing gaan er alleen JDBC calls richting de SQL Server machine.

[zneek]

Een klein server programma wordt het niet. Elke im/export slag worden er 50.000+ records behandeld. Dat wordt dus nogal een redelijk load, zelfs bij het 1 keer per uur laten draaien van de functies.

Bedankt voor de info verder. Als er nog mensen zijn die wat meer inzicht hebben in Transact-SQL... graag.

Ow, en de conversie is idd ingewikkelder dan een 1-op-1 vertaling van velden. Validatie en meerdere lookups per te converteren record zijn nodig.

[Alarmnummer]

Op dinsdag 16 juli 2002 15:01 schreef zneek het volgende:
Een klein server programma wordt het niet. Elke im/export slag worden er 50.000+ records behandeld. Dat wordt dus nogal een redelijk load, zelfs bij het 1 keer per uur laten draaien van de functies.

Bedankt voor de info verder. Als er nog mensen zijn die wat meer inzicht hebben in Transact-SQL... graag.

Ow, en de conversie is idd ingewikkelder dan een 1-op-1 vertaling van velden. Validatie en meerdere lookups per te converteren record zijn nodig.

Met klein/groot wordt over het algemeen de hoeveelheid functionaliteit (complexiteit) bedoelt dat een applicatie bezet, en niet zozeer de hoeveelheid bewerkingen op records per tijds eenheid.

[zneek]

Op dinsdag 16 juli 2002 15:05 schreef Alarmnummer het volgende:

[..]

Met klein/groot wordt over het algemeen de hoeveelheid functionaliteit (complexiteit) bedoelt dat een applicatie bezet, en niet zozeer de hoeveelheid bewerkingen op records per tijds eenheid.

Ja ok, maar de SQL Server wordt al door 3 andere servers gebruikt(o.a. webkoppeling). Die server ontlasten is dus volgens mij geen slecht idee.

[Alarmnummer]

Ik ben verder niet thuis in SQL Server gebeuren. Maar ik neem aan dat je de server extra gaat belasten als alle transformaties daarop worden uitgevoerd. Aangezien jij je drukt maakt om de load op die server is dan die transformatie op de sql server niet uitgesloten?

[zneek]

Op dinsdag 16 juli 2002 14:59 schreef Bobco het volgende:
Als het converteren moeilijker is dan veld 1 -> kolom 1 enzvoorts, dan zou ik geneigd zijn een Java-only oplossing te kiezen. Als de Schedule eisen niet ingewikkelder zijn dan een per x seconden kijken of er files staan die geimporteerd moeten worden, dan is dat uitermate simpel te regelen met een aparte Java-thread die niets anders doet dan slapen en om de x seconden kijken of er een file is. Is die er dan kan er een verwerkings-thread gestart worden.

Het belangrijkste criterium is denk ik de ingewikkeldheid van de conversie. Als je dingen wilt zoals echte validatie van gegevens, conditionele conversie enz dan zou ik de flexibiliteit van Java gebruiken.

Een ander punt van overweging is misschien de scheiding van de taken. Als een DTS package de file moet kunnen zien, dan betekent dat ook dat die file bereikbaar moet zijn via het filesysteem van de machine waarop SQL Server draait. In de Java oplossing gaan er alleen JDBC calls richting de SQL Server machine.

Maar wat weegt dan zwaarder? Een DTS package die 1 keer een CSV file over het netwerk pompt, of een Java applicatie die duizenden JDBC calls doet over het netwerk? Ik vermoed dat het eerste minder belastend voor het netwerk is. Maar, de load, het uitvoeren van de logica belast de SQL server weer.

[Bobco]

Op dinsdag 16 juli 2002 15:01 schreef zneek het volgende:
Ow, en de conversie is idd ingewikkelder dan een 1-op-1 vertaling van velden. Validatie en meerdere lookups per te converteren record zijn nodig.

Kun je die validaties beschrijven in termen van SQL constraints? Dan kun je alsnog redelijk eenvoudig een oplossing met DTS bouwen omdat de database dan automatisch een groot gedeelte van je validatie doet.

Wat ik hierboven zei over JDBC calls is natuurlijk niet helemaal correct. Een type 4 JDBC driver zal het native database protocol gebruiken (bijv SQL*net voor Oracle) voor communicatie met de database server.

Als je niet volledig vast zit aan de keuze voor SQL Server biedt een Java oplossing nog een voordeel: je kunt de functionaliteit veel beter los houden van de database. In theorie biedt je dat de mogelijkheid om een willekeurig ander RDBMS te gebruiken. Kan z'n voordelen hebben, ook licentie-technisch.

[zneek]

Op dinsdag 16 juli 2002 15:12 schreef Alarmnummer het volgende:
Ik ben verder niet thuis in SQL Server gebeuren. Maar ik neem aan dat je de server extra gaat belasten als alle transformaties daarop worden uitgevoerd. Aangezien jij je drukt maakt om de load op die server is dan die transformatie op de sql server niet uitgesloten?

Dat is een afweging. Als ik nu 50% ontwikkeltijd bespaar (en dus kosten voor de klant) maar de gemiddelde CPU belasting op de SQL Server omhoog gaat van 50 naar bijvoorbeeld 75%, dan is het wel een goede keuze. Als de SQL Server helemaal aan de kook raakt is het geen optie, uiteraard. Vandaar ook mijn vraag, wie heeft er inzicht in DTS/Stored procedus en Transact-SQL en kan vertellen of de voordelen opwegen tegen de nadelen?

[Alarmnummer]

Je kan met 1 jdbc call ook een enorme reeks data ophalen. Je kan het zelfs met een cached resultset bewerken zonder contact te onderhouden met de server. Je hoeft dus niet voor ieder record contact te leggen met de database. Maar ik moet toegeven dat ik er weinig zinnigs meer over kan zeggen om dat ik niet weet hoe jullie netwerk eruit ziet, en geen gegevens weet van veel jdbc calls en de overhead daarvan op het netwerk (en de sql server).

[Bobco]

Op dinsdag 16 juli 2002 15:12 schreef zneek het volgende:

[..]

Maar wat weegt dan zwaarder? Een DTS package die 1 keer een CSV file over het netwerk pompt, of een Java applicatie die duizenden JDBC calls doet over het netwerk? Ik vermoed dat het eerste minder belastend voor het netwerk is. Maar, de load, het uitvoeren van de logica belast de SQL server weer.

Je kunt in JDBC ook batches uitvoeren. Dit is een duidelijke vermindering van de netwerkbelasting omdat updates en inserts gebundeld worden in 1 netwerk call.

Als het je inderdaad gaat om zo weinig mogelijk belasting van de machine waarop SQL Server draait dan blijft eigenlijk alleen de Java oplossing over. De inserts moet je hoe dan ook doen (geldt voor beide oplossingen) en met een Java-conversie programma kun je die load helemaal op een andere machine leggen.

Edit: Alarmnummer, kun jij misschien in het vervolg 1 minuutje later posten?

[zneek]

Op dinsdag 16 juli 2002 15:13 schreef Bobco het volgende:

[..]

Kun je die validaties beschrijven in termen van SQL constraints? Dan kun je alsnog redelijk eenvoudig een oplossing met DTS bouwen omdat de database dan automatisch een groot gedeelte van je validatie doet.

Wat ik hierboven zei over JDBC calls is natuurlijk niet helemaal correct. Een type 4 JDBC driver zal het native database protocol gebruiken (bijv SQL*net voor Oracle) voor communicatie met de database server.

Als je niet volledig vast zit aan de keuze voor SQL Server biedt een Java oplossing nog een voordeel: je kunt de functionaliteit veel beter los houden van de database. In theorie biedt je dat de mogelijkheid om een willekeurig ander RDBMS te gebruiken. Kan z'n voordelen hebben, ook licentie-technisch.

Dat klopt, en dat is ook zeker een overweging. Alleen ben ik in de keuze van het RDBMS afhankelijk van de keuze van de klant. Ze draaien daar nu SQL Server, en hebben alle benodigde licentie. Tenzij MicroSoft een "niet goed geld terug" beleid heeft, zitten ze daar dus aan vast.

[Alarmnummer]

Op dinsdag 16 juli 2002 15:16 schreef Bobco het volgende:
Edit: Alarmnummer, kun jij misschien in het vervolg 1 minuutje later posten?

Is goed, ik post op de oneven minten en jij op de even?

[zneek]

Op dinsdag 16 juli 2002 15:18 schreef Alarmnummer het volgende:

[..]

Is goed, ik post op de oneven minten en jij op de even?

Dan houd ik mijn mond eff, ok?

[zneek]

Alarmnummer: Ik ken jou.

EDIT: Is [e-mail] je echte mailadres?

[Alarmnummer]

Maar misschien zou je een soort dummie procedure kunnen schrijven op de sql server en een java client die contact opneemt met de db en wat vergelijkbare onzinnige bewerkingen erop uitvoert. Misschien kan je dan een goed oordeel geven?

Alarmnummer: Ik ken jou.

ojee.. is dit goed of slecht nieuws?

is [e-mail] je echte mailadres?

Yepz

Aangezien je naam Zneek is, zal je wel uit Sneek komen, en dan moet je op de Hanze hebben gezeten. Jij bent dus een klasgenoot van mij geweest.. Nu nog even uitzoeken welke

[Verwijderd]

DTS is speciaal voor import & conversies gebouwd. Je kunt daarin middels bv VB scripts de conversie sturen. 1:1 imports kun je gewoon importeren middels de ADO csv driver. Ik zou zeker eerst dat onderzoeken want een converter bouwen die de imports doet is veelal nogal wat werk en ik spreek uit ervaring (toen DTS nog niet zo goed was als nu heb ik 2 van die dingen gebouwd)

[edit]
als je de custom made route opgaat: gebruik stored procs om data te storen in je sqlserver. Dus je importer leest data in, en roept stored procs aan om die data te storen. Inserts zijn erg snel, maar updates van rows kunnen nog wel lang duren.

Hoe meer werk je vooraf kunt doen (dus wanneer je die csv files schrijft) hoe beter.

Ter indicatie: een importer die ik 4 jaar geleden schreef voor het importeren van csv files (in VB) importeert 700.000 regels (in meerdere files, naar nog meer tables) in 17 minuten op een p3-1ghz dell server met win2k en sqlserver.

Waar komen de CSV files vandaan? Want tegenwoordig zijn voor erg veel databases odbc drivers te krijgen waardoor je dus niet via csv files hoeft maar direct van database naar database kunt repliceren.

[zneek]

Op dinsdag 16 juli 2002 15:24 schreef Alarmnummer het volgende:
Maar misschien zou je een soort dummie procedure kunnen schrijven op de sql server en een java client die contact opneemt met de db en wat vergelijkbare onzinnige bewerkingen erop uitvoert. Misschien kan je dan een goed oordeel geven?
[..]

ojee.. is dit goed of slecht nieuws?
[..]

Yepz

Aangezien je naam Zneek is, zal je wel uit Sneek komen, en dan moet je op de Hanze hebben gezeten. Jij bent dus een klasgenoot van mij geweest.. Nu nog even uitzoeken welke

ARGH, nee, aub niet uit Sneek. Ik kom zeker niet uit Sneek. Ik gebruik ZneeK omdat Snake (mijn eerste gamenick) al heeeeeel veel gebruikt wordt online. ZneeK is een NL verbastering van Snake. Dus, weer een mysterie opgelost.

[zneek]

Op dinsdag 16 juli 2002 15:30 schreef Otis het volgende:
DTS is speciaal voor import & conversies gebouwd. Je kunt daarin middels bv VB scripts de conversie sturen. 1:1 imports kun je gewoon importeren middels de ADO csv driver. Ik zou zeker eerst dat onderzoeken want een converter bouwen die de imports doet is veelal nogal wat werk en ik spreek uit ervaring (toen DTS nog niet zo goed was als nu heb ik 2 van die dingen gebouwd)

Thanks, zoiets wilde ik horen. Als ik alleen al denk aan alle classes die ik moet schrijven om een basis te creeeren waarbinnen die hele conversie moet draaien.... Als dat Transact-SQL een beetje handig te gebruiken is heeft dat toch mijn voorkeur denk ik.

Weet je wat goede T-SQL example sites?

[Alarmnummer]

Ik vond mijn deductief vermogen nog niet eens zo slecht

Maar je bent dus een oud klas genoot, welkom op tweakers zou ik zeggen

[zneek]

welkom? nou, ik post niet zoveel, maar ben toch al een jaartje of wat trouwe bezoeker

[zneek]

De CSV files komen uit een kassasysteem, en een ODBC koppeling, mnee. Het systeem is NET beschikbaar voor Windows

De enige koppeling die ik kan vinden is een Hyper File koppeling, maar daar kan ik schrikbarend weinig over vinden.

[deBUG]

Geen SQL Server maar Oracle gebruiken en gewoon SQL*Loader.

[zneek]

Op dinsdag 16 juli 2002 15:50 schreef deBUG het volgende:
Geen SQL Server maar Oracle gebruiken en gewoon SQL*Loader.

Lees aub hele topic voordat je reageert. Oracle is geen optie.

[Alarmnummer]

Op dinsdag 16 juli 2002 15:46 schreef zneek het volgende:
De CSV files komen uit een kassasysteem, en een ODBC koppeling, mnee. Het systeem is NET beschikbaar voor Windows

De enige koppeling die ik kan vinden is een Hyper File koppeling, maar daar kan ik schrikbarend weinig over vinden.

Je kan met java vrij eenvoudig voor iedere vorm van tabulaire data een jdbc driver schrijven. Op javaworld staan er een aantal artikelen over.

En ik weet verder niet hoe gecompliceerd die data is, maar anders kan je er ook zo een parser voor schrijven die alles inlees en converteerd naar java objecten, die je dan alsnog naar de db kan sturen.

[Annie]

Op dinsdag 16 juli 2002 15:36 schreef zneek het volgende:
Als dat Transact-SQL een beetje handig te gebruiken is heeft dat toch mijn voorkeur denk ik.

Weet je wat goede T-SQL example sites?

Je kan om wat ideeen op te doen even gaan kijken op bijv. http://www.sqlmag.com
Maar eigenlijk raad ik aan om ergens een goed boek vandaan te halen. Btw. het gaat hier om het maken van DTS packages en dat is iets totaal anders dan T-SQL (en een vak apart ).

Op dinsdag 16 juli 2002 15:50 schreef deBUG het volgende:
Geen SQL Server maar Oracle gebruiken en gewoon SQL*Loader.

*NOT AMUSED*
SQL*Loader? Heb je toevallig al eens gekeken naar DTS? Nee, dat dacht ik al.

[zneek]

Op dinsdag 16 juli 2002 16:39 schreef Annie het volgende:

[..]

Je kan om wat ideeen op te doen even gaan kijken op bijv. http://www.sqlmag.com
Maar eigenlijk raad ik aan om ergens een goed boek vandaan te halen. Btw. het gaat hier om het maken van DTS packages en dat is iets totaal anders dan T-SQL (en een vak apart ).
[..]

*NOT AMUSED*
SQL*Loader? Heb je toevallig al eens gekeken naar DTS? Nee, dat dacht ik al.

Die DTS packages lukt wel. Ik zal alleen een stuk conversie in storedprocedures moeten gooien, en das wel weer T-SQL

[Annie]

Op dinsdag 16 juli 2002 16:45 schreef zneek het volgende:

[..]

Die DTS packages lukt wel. Ik zal alleen een stuk conversie in storedprocedures moeten gooien, en das wel weer T-SQL

My bad. Had op de eerste pagina niet gezien dat je ook binnen de database lookups en validatie wilde doen. Dacht dat je alleen de data wilde transformeren tijdens de import.