abonnementen ibood.com bol.com Gearbest
pi_174242478
Als beta die geen IT gestudeerd heeft ben ik al een paar jaar lang werkzaam in de IT of anders banen waarbij een grote IT component aanwezig is (denk aan o.a. Data Science). Daarbij heb ik ervaring opgedaan in meerdere talen. Taal die me het best af gaat is Python, ik kon al Pythonic programmeren voordat ik wist wat dat betekende ;) Andere taal waarmee ik ervaring heb is C#, ik heb geen uitgesproken voor of afkeur voor C#, hangt een beetje van het project af, kan er echter in principe wel in meekomen alhoewel ik dan weer niet op software patterns zit te wachten.

Met SQL ben ik ook in aanraking gekomen, echter het ging nooit verder dan simpele queries, ik heb ook nooit de behoefte gehad om meer van SQL te weten. Vaak was ik blij dat we de data zo snel mogelijk uit de db gehaald hadden waarna we in Python, C# of desnoods VBA wel het echte werk gingen doen.

Nu zit ik echter helaas op een project waarbij voor de verandering vrij complexe SQL queries geschreven moeten worden, het zijn eigenlijk halve programma's die wel meerdere pagina's kunnen beslaan zou je ze uitprinten. Dit soort analyses zou ik met Python of eventueel C# zo uit de mouw schudden, echter omdat ik niet bekend genoeg ben met SQL gaat het me enorm stroef af. Ik zit eigenlijk gewoon behoorlijk gefrustreerd achter de computer ... het lukt niet ... en in Python doe ik het met mijn ogen dicht.

Nu is mijn vraag, waarop ik serieuze antwoorden hoop te krijgen: is mijn gefrustreerde gevoel terecht en is SQL een achterhaalde taal waarmee je je beter kan beperken tot eenvoudige analyses of is het de moeite waard om hier vol in te duiken? Ik overweeg namelijk serieus om met het project te stoppen, ongetwijfeld tot onbegrip en teleurstelling van de mensen waarmee ik samenwerk.

Paar jaar terug had ik de kans om me met SAS bezig te houden. Hoewel de grafische schil op SAS prima in elkaar zit, zit er onder de oppervlak wel een archaïsch taaltje van voor WW2 (grapje) onder. Ik was dan ook blij dat ik toen niet voor SAS gekozen heb en me met een high level (nog hoger dan Python, ja ze bestaan) bezig heb kunnen houden wat me gelukkig zeer goed af ging.

[ Bericht 2% gewijzigd door KromBuiten op 06-10-2017 23:20:59 ]
pi_174243035
quote:
is mijn gefrustreerde gevoel terecht en is SQL een achterhaalde taal waarmee je je beter kan beperken tot eenvoudige analyses of is het de moeite waard om hier vol in te duiken?
imho is het absoluut de moeite waard sql beter te leren kennen.

Het lijkt mij vele malen efficiënter om met een kleine dataset dingen te doen dan gewoon maar de (bij wijze van spreken) hele database in het geheugen van de cliënt te zetten
pi_174243103
Sorry jongen.
SQL is het DBMS en zal dat voorlopig blijven.
Koop het boek Het SQL leerboek.
Heb ik ook, goed boek. 700 blz, 60 euro, is een standaardwerk en goed te doen.
Ik vind mijn buurman een toffe peer
  Moderator vrijdag 6 oktober 2017 @ 22:27:43 #4
54263 crew  Pharkus
eeuwig vader, deeltijd autist
pi_174244369
quote:
1s.gif Op vrijdag 6 oktober 2017 21:02 schreef d4v1d het volgende:
Wat een ontiegelijk lange OP voor een simpele vraag..
Ik onderschrijf de antwoorden hierboven wel. Maar het is toch altijd wel het afwegen waard waar je wat doet, voor je het weet zit je een webserver in stored procedures te schrijven omdat alles in SQL moet.
Een vel leeg papier kan altijd nog een mooie tekening worden.
pi_174244769
quote:
1s.gif Op vrijdag 6 oktober 2017 21:27 schreef Sigaartje het volgende:
Sorry jongen.
SQL is het DBMS en zal dat voorlopig blijven.
Koop het boek Het SQL leerboek.
Heb ik ook, goed boek. 700 blz, 60 euro, is een standaardwerk en goed te doen.
Dat sql prominent is en blijft wil ik wel geloven, mijn vraag is meer of het inderdaad een enigszins onhandig taaltje is? Waarom zou ik me niet gewoon bezig blijven houden met alternatieven zoals python + pandas die, hoewel kleiner, wel opkomend zijn.
pi_174244897
PHP bijvoorbeeld, ook zo goed als een standaard, toch zou in er nooit in willen programmeren. Waarom, krakkemikkig en interieur tov al het andere.
  vrijdag 6 oktober 2017 @ 22:54:45 #7
394547 versterker
- Dat kan HARDER! -
pi_174244936
quote:
5s.gif Op vrijdag 6 oktober 2017 22:47 schreef KromBuiten het volgende:

[..]

Dat sql prominent is en blijft wil ik wel geloven, mijn vraag is meer of het inderdaad een enigszins onhandig taaltje is? Waarom zou ik me niet gewoon bezig blijven houden met alternatieven zoals python + pandas die, hoewel kleiner, wel opkomend zijn.
Performance?

Als je de data in één keer goed uit die database trekt heb je nabewerking in iets relatief traags als Python helemaal niet meer nodig. SQL is nu eenmaal de standaard, en daarmee leren omgaan is zeker een goede investering van je tijd.
pi_174245140
SQL is niet echt een programmeertaal he?
Het is een databasetaal die je bijvoorbeeld vanuit Python aan kunt roepen.
Ik vind mijn buurman een toffe peer
pi_174245335
quote:
0s.gif Op vrijdag 6 oktober 2017 22:54 schreef versterker het volgende:

[..]

Performance?

Als je de data in één keer goed uit die database trekt heb je nabewerking in iets relatief traags als Python helemaal niet meer nodig. SQL is nu eenmaal de standaard, en daarmee leren omgaan is zeker een goede investering van je tijd.
Performance is duidelijk en bekend, echter tegenwoordig is python voor veel analyse klussen snel genoeg en is performance dus geen issue meer.

En wbt investering, php is ook standaard, toch weiger ik te investeren in die taal.

Al met al goed bedoelde argumenten, ze overtuigen me echter niet.
pi_174245391
quote:
0s.gif Op vrijdag 6 oktober 2017 23:02 schreef Sigaartje het volgende:
SQL is niet echt een programmeertaal he?
Het is een databasetaal die je bijvoorbeeld vanuit Python aan kunt roepen.
I know
Toch worden er hier complete programma's (algoritmen) in sql geschreven. Mijn vraag is dus hoe handig dat is, afgezien van performance en standaard.
  vrijdag 6 oktober 2017 @ 23:21:23 #11
272631 redboyke
Say NO to Pre-Orders
pi_174245534
quote:
1s.gif Op vrijdag 6 oktober 2017 23:14 schreef KromBuiten het volgende:

[..]

I know
Toch worden er hier complete programma's (algoritmen) in sql geschreven. Mijn vraag is dus hoe handig dat is, afgezien van performance en standaard.
waarom zouden mensen iets dat trager is implementeren als je GB's aan data hebt?dan telt elke milliseconde.
Ik ben Belg.
pi_174245616
quote:
0s.gif Op vrijdag 6 oktober 2017 23:21 schreef redboyke het volgende:

[..]

waarom zouden mensen iets dat trager is implementeren als je GB's aan data hebt?dan telt elke milliseconde.
Omdat niet in elke situatie elke ms telt.

Mocht hem wel eens een nacht lang laten draaien.
pi_174245728
Sql is nog steeds alomtegenwoordig, je kan er niet omheen. Als je iets serieus met data en databases wil doen is het ontzettend handig als je ook sql beheerst. Tegenwoordig heb je in vrijwel alle talen, ook in python, wel sql "wrappers", aka database abstractie lagen, aka object relational mapping tools, waardoor je in theorie geen ruwe sql meer hoeft te schrijven, maar in de praktijk betaal je daar in bepaalde gevallen toch wel een flinke performance prijs voor. Dan blijft het vaak toch nog efficiënter om ruwe sql te gebruiken.

Let wel op dat er meerdere sql "dialecten" bestaan; de basis is hetzelfde maar details verschillen. MS sql is anders dan mysql en dat is ook weer anders dan postgresql bijvoorbeeld.
  zaterdag 7 oktober 2017 @ 03:02:26 #14
19440 Maanvis
Centuries in a Lifetime
pi_174248788
Er is eigenlijk niks mis met SQL, was bij een conferentie waar zelfs de bedenkers van Hadoop voor een bepaalde applicatie een hele mongodb onrelationele database hadden opgezet, maar toch teruggingen naar relationele database met nosql achtige uitbreidingen omdat het anders gewoon niet werkte :).

Ik vind SQL in vergelijking met de programmeertalen die voor Python kwamen (uitgezonderd Pascal) juist erg makkelijk. Dit even afgezien van het feit dat het niet echt een programmeertaal is.. maargoed, ik ken er inmiddels zoveel, van graphql tot plc programma's dat het begrip 'programmeertaal' niet echt meer iets anders betekent dan iets om een machine instructies te geven.
Wat voor mij het makkelijkste werkt bij complexe SQL queries is om simpel te beginnen en van 'achter naar voor' te werken. Dus stel je wilt uiteindelijk in je queryresultaat de usernames die in een topique reageren dan moet je natuurlijk het databasemodel wel kennen.

Als je geluk hebt en de database is door een programmeur, niet door een databaseadministrator ontworpen, dan heb je eigenlijk altijd wel een surrogate key voor elk record. Zoals hier op FOK! elke post een postid heeft :). En waarschijnlijk ook een topiqueid en een userid. Dus dan begin je met alle posts te selecteren van een bepaald topiqueid, en daarna werk je met een inner join op userid naar de user tabel waar je waarschijnlijk weer de naam zult vinden van de users. Dan nog even een distinct er op en wat voor sort je dan ook wilt, en klaar.

Mbt de data zsm uit de DB halen en er dan met python wat mee doen. Dat is leuk voor kleine databasejes, maar zo goed als alle SQL servers zijn veel beter in dat soort 'heavy lifting' dan python ooit zou kunnen omdat SQL gebruik kan maken van indexen en out of the box al meestal een gedeelde query cache heeft. Sommige mensen zijn zelfs zo dom om via python uiteindelijk een soort subquery te gaan schrijven (iets wat in 2003 misschien okay was, nu niet meer).

Nu zijn er voor python ook ORMs (object relactional mappers) beschikbaar zodat je nooit meer een sql query hoeft te schrijven :). Zelf ben ik ERG tevreden over pony ORM. https://ponyorm.com/ dan kan je iig nadat je je databasemodel hebt uitgelegd in een aantal classes je python code gewoon schrijven en pony vertaalt dat naar mysql, sqlite of postgresql.
Als je dan je database nabouwt op je locale machine met fake data, en die queries dan weer opslaat met de debugger mode van pony dan maakt ie er zelf een fatsoenlijke query van (zelfs geoptimaliseerd in sommige gevallen). Vroeger kon je dat zelfde ook doen met access.. dan maakte je complexe dingen door die lijntjes aan elkaar vast te slepen en dan maakte je daar modificaties in in de query editor ;).

Als je complete programma's in SQL schrijft dan ben je wel gek als je niet views gebruikt voor de querydelen die je vaak gebruikt, en stored procedures voor bewerkingen die je vaak moet uitvoeren. Postgresql heeft zelfs materialized views (dat zijn eigenlijk gewoon tabellen die gevuld worden met de uitkomst van een query en met een refresh commando ververst kunnen worden);

Van alle dingen die ik heb geleerd op mijn informatica-opleiding (en ja daar zat pascal en c++ programmeren in ) heb ik nu dagelijks nog het meeste aan dat ik destijds ook SQL heb geleerd.

En verder; als je bij een bedrijf werkt waar je dit soort dingen op FOK! moet vragen ipv aan je collega's kunt/durft te vragen.. dan werk je voor het verkeerde bedrijf :)

[ Bericht 3% gewijzigd door Maanvis op 07-10-2017 03:16:39 ]
... This action will have consequences ...
"If Tetris has taught me anything, it's that errors pile up and accomplishments disappear"
pi_174250545
Sql is natuurlijk wel een programmeertaal maar geen imperatieve taal zoals python, maar een declaratieve taal, net zoals bijv prolog. Ipv stap voor stap te zeggen wat de computer moet doen om tot een resultaat te komen, beschrijf je met sql hoe het resultaat eruit moet zien, en de stappen om daar te komen bepaalt de computer.
pi_174269531
Dank voor de reacties, ik ben niet de enige die er mee zit te worstelen. Vond zat discussies en o.a. deze informatieve site:

PostgreSQL vs. pandas — how to balance tasks between server and client side

1*ltQN5rQ5tI0fcQz7fMqsww.png

Every day — somewhere on earth: A typical “server-side vs. client-side” debate
pi_174361875
quote:
0s.gif Op vrijdag 6 oktober 2017 22:52 schreef KromBuiten het volgende:
PHP bijvoorbeeld, ook zo goed als een standaard, toch zou in er nooit in willen programmeren. Waarom, krakkemikkig en interieur tov al het andere.
U beseft dat Python en PHP niet heel veel verschillen? Sterker, dat PHP qua performance Python op veel vlakken heeft ingehaald?

Overigens haal ik deze puur aan omdat dergelijke opmerkingen meestal gemaakt worden door mensen die de talen gewoon niet snappen :P
  donderdag 12 oktober 2017 @ 07:02:46 #18
8130 raptorix
THAI CHARACTER MAITAIKHU
pi_174365960
Peformance beter in Python dan in SQL? Wat een flauwekul, het hele voordeel van SQL is juist dat je het voordeel van indices hebt, als je een table met 10 miljoen records hebt, en jij wilt op de client gaan filteren dan wens ik je veel succes, je moet sowieso die 10 miljoen records naar je client halen, dus dat gaat hem niet worden.

Tjah en je kunt SQL vrij ingewikkeld maken, zeker als je met zaken als cursors gaat werken.

Als tip, deel je SQL op, je kunt bijvoorbeeld vrij makkelijk gebruik maken door tables in variabelen op te slaan, en daar weer een query tegen aan te runnen, welliswaar is dat vaak niet de meest optimale manier, maar het voorkomt vaak ingewikkelde joins.
pi_174405810
SQL gaat nergens heen.
Databases blijven, dus je lekker vastbijten in het project en investeren in meer SQL kennis.
pi_174416777
Ik werk al tientallen jaren met SQL. Ik heb SP's geschreven die qua complexiteit niet onderdoen aan een reguliere populaire programmeertaal.

Er is een balans in de keuzes vind ik. Voor data lifting is sql natuurlijk perfect. Maar als je herbruikbare code wilt hebben, of complexe bewerkingen, testbaarheid van code, schaalbaarheid: dan is het een crime.

Soms (vaak) ontkom je er gewoon niet aan. Een query is nou eenmaal sneller geschreven dan een equivalent in een programmeertaal. Gebruik je een ORM, dan moet je maar net die syntax kennen.

Ik kan me altijd nog mijn eerste SQL-les herinneren: een database is geen calculator. gebruik het voor opvragingen, niet voor berekeningen. In praktijk maar al te vaak niet aan deze regel gehouden, maar sommige problemen van nu zouden niet zijn opgetreden als ik de oplossing niet als sql-query had aangedragen. Maar ach. de klant kiest al te vaak voor de snelle (goedkope) oplossing. Met een beetje geluk zullen de problemen niet optreden in de praktijk. (95% van wel natuurlijk, maar dat is niet genoeg reden om niet de snelle oplossing te kiezen)
  zaterdag 14 oktober 2017 @ 17:09:20 #21
45206 Pietverdriet
Ik wou dat ik een ijsbeer was.
pi_174416905
Als TS zich niet lekker voelt bij sql of het niet kan moet ie een ander project gaan zoeken
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
  zaterdag 14 oktober 2017 @ 17:35:08 #22
19440 Maanvis
Centuries in a Lifetime
pi_174417446
quote:
0s.gif Op zaterdag 14 oktober 2017 17:01 schreef athlonkmf het volgende:
Ik werk al tientallen jaren met SQL. Ik heb SP's geschreven die qua complexiteit niet onderdoen aan een reguliere populaire programmeertaal.

Er is een balans in de keuzes vind ik. Voor data lifting is sql natuurlijk perfect. Maar als je herbruikbare code wilt hebben, of complexe bewerkingen, testbaarheid van code, schaalbaarheid: dan is het een crime.

Soms (vaak) ontkom je er gewoon niet aan. Een query is nou eenmaal sneller geschreven dan een equivalent in een programmeertaal. Gebruik je een ORM, dan moet je maar net die syntax kennen.

Ik kan me altijd nog mijn eerste SQL-les herinneren: een database is geen calculator. gebruik het voor opvragingen, niet voor berekeningen. In praktijk maar al te vaak niet aan deze regel gehouden, maar sommige problemen van nu zouden niet zijn opgetreden als ik de oplossing niet als sql-query had aangedragen. Maar ach. de klant kiest al te vaak voor de snelle (goedkope) oplossing. Met een beetje geluk zullen de problemen niet optreden in de praktijk. (95% van wel natuurlijk, maar dat is niet genoeg reden om niet de snelle oplossing te kiezen)
Als je altijd maar baggerkwaliteit levert omdat de klant dat wil dan krijg je dat later in je carriëre terug als slechte naam :'(
... This action will have consequences ...
"If Tetris has taught me anything, it's that errors pile up and accomplishments disappear"
pi_174419870
quote:
0s.gif Op zaterdag 14 oktober 2017 17:35 schreef Maanvis het volgende:

[..]

Als je altijd maar baggerkwaliteit levert omdat de klant dat wil dan krijg je dat later in je carriëre terug als slechte naam :'(
Er is een aantal niveau’s aan verschil tussen baggerkwaliteit en minder onderhoudbaar.
Als je 10x de ontwikkeltijd wilt verkopen kom je nooit voorbij het offertetraject.
pi_174440308
Problem solved, mag het op mijn eigen manier doen. Dat betekent dus eenvoudige queries waarna alle actie in Python plaats vind.

Iedereen bedankt voor de reacties.
  maandag 16 oktober 2017 @ 15:47:52 #25
19440 Maanvis
Centuries in a Lifetime
pi_174452950
quote:
1s.gif Op zondag 15 oktober 2017 21:57 schreef KromBuiten het volgende:
Problem solved, mag het op mijn eigen manier doen. Dat betekent dus eenvoudige queries waarna alle actie in Python plaats vind.

Iedereen bedankt voor de reacties.
quoted voor het nageslacht (en wie de python weer om gaat schrijven naar sql)
... This action will have consequences ...
"If Tetris has taught me anything, it's that errors pile up and accomplishments disappear"
abonnementen ibood.com bol.com Gearbest
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')