paniek . . . moet (complexe) SQL scripts schrijven

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

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.

quote:

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.

quote:

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.

SQL is niet echt een programmeertaal he?
Het is een databasetaal die je bijvoorbeeld vanuit Python aan kunt roepen.

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.

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 ]

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.

quote:

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

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.

SQL gaat nergens heen.
Databases blijven, dus je lekker vastbijten in het project en investeren in meer SQL kennis.

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 TS zich niet lekker voelt bij sql of het niet kan moet ie een ander project gaan zoeken

quote:

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

quote:

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.

quote:

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)