So SQL is basically just setting keywords and filters to search through a spreadsheet?Does it get much more complicated than this?
>>107088204Nope
>>107088204sometimes you search through two or more spreadsheets
>>107088204It gets a little bit more complicated sometimes, because sometimes you have to combine multiple spreadsheets together, search through the results of those, and then use those results to filter another spreadsheet, and so on.
>>107088204Its not very complicated, but its more of a means to an end than the actual end game. If you want to do any sort of meaningful filtering with a lot of data, you need to use multiple sheets, or tables. Excel and other spreadsheet editors are horrible at that
>>107088204databases have powerful manipulations of matrices. spreadsheets don't. databases are more like APL than spreadsheets, though admittedly it would be nice if spreadsheets sucked less.
>>107088204Well you will need to be able to cascade (remove) child tables when the parent dies, and reference keys in other SQL files.
>>107088204Yes, but not for 90% of the people who will ever use it.
>>107088204you also have>data types validation>constraints>transactions (very useful feature)>access control>subqueries>joinssupport for these features varies heavily across RDBMS implementations, so ymmv
>>107088204It gets more interesting when you have multiple tables, transactions, locks, etc.Basic sql is not hard but it still filters millions
query composition in raw SQL is absolute trashyou are basically required to use a query builder in your language of choiceserializable transactions are a good defaultuse fucking constraints as much as possible: https://borretti.me/article/you-need-more-constraintspick a solid naming scheme and stick to it (remember that tables, indexes, constraints, and other things share a namespace)investigate recursive queriesdenormalize your data and get very familiar with joins/subqueries
>>107088569normalize*
>>107088569almost forgot: figure out a good migrations scheme early onmake sure that your migrations can run non-SQL code such that you can perform algorithmic work when mandated (such as in the case of calculating some result for each row of some table and adding it as a column)
>>107088204haha DELETE FROM co_container WHERE wid IS 2 AND SQRT(POWER(0 - x, 2) + POWER(0 - z, 2)) <= 300; go brrrrr
DELETE FROM co_container WHERE wid IS 2 AND SQRT(POWER(0 - x, 2) + POWER(0 - z, 2)) <= 300;
>>107088204No but also yes.Its more that its easy to introduce issues with (in)efficency and redundancyMaintaining clean sql is the difficult part
I think of spreadsheets effectively as GUI hyper calculator. With a small dataset, this is a very powerful tool.SQL is more of an abstraction layer over general data processing. In SQL, data will often be filtered, reshaped and joined, sometimes several times in a single query. This would not be easy to do in GUI.>>107088420>views>>107088569>query composition in raw SQL is absolute trashHave you tried getting gud? Worked out for me.
Normal forms are the hardest.
>>107089245SQL is not normal forms.Normal forms is how you should think about data in general.
>>107088569>you are basically required to use a query builder in your language of choiceyou must suck so muchdo you do bachelor parties?
>>107088569>query composition in raw SQL is absolute trashwtf
>>107088393>powerfulWhy is this the only adjective every brainlet programmer knows?
>>107089238>>107089304>>107089363if you are not using something like HoneySQL from Clojure, Ecto from Elixir, or Postmodern from Common Lisp, then you are big retarded
>>107088204>Does it get much more complicated than this?Not at all! You pretty much figured it out. Now it is time to go interview for your new $160k/year job as a DBA. Enjoy anon, you earned it!
>>107088204what sqlite client is this?
>>107088204>why is declarative language declarative
>>107088204the entire language and expertise has been solved by chatgpt
>>107090039It looks like antares to mehttps://github.com/antares-sql/antares
>>107088204With Postgres you can do a lot of other fancy things, like using LISTEN/NOTIFY with triggers to steam changes to tables through to the application, and if done right directly through a GraphQL subscription or SSE or gRPC.Or you can have application level locks centralized in the database, or implement a proper work queue, or use it as a cache.Then you have extensions which allow you to do pretty much anything.git gud
sql is a very expensive xlookup (you aren't still using vlookups, are you anon?)
Sometimes you have complex interlinked spreadsheets so you need to compose complex queries. For example select one sheet and then join it with another but instead of just joining the rows of the another sheet you build one single summary row from all rows that matched the parent sheet. And you can have these kind of connections for many levels deep down.
>>107088204The next great filter is aggregate functions. Its SQLs version of pointers in how it stumps people.
>>107090076thanks
>>107088393Is APL superior to databases?
>>107090132Oh what’s really going to bake your noodle is window functions.
>>107088569>denormalize your data and get very familiar with joins/subqueriesIts 2025 grandpa. Space is cheap and I aint got time to wait for no join.
>>107088204I learned SQL in 2007 without the internet or a manual just by looking at the source code of some web app. I'm also really stupid. SQL is easy and powerful
>>107088204Sql doesnt really ever get complicated.Hardest you can do without making dynamic procedures to regenerate views with columns or similar is row level security. Too many predicates and youre slow, not enough predicates and do you have the right security.The real difficulty in sql comes from having to explain to pajeet for the third time to not use a fucking cte on a view that counts because hes spooling the worktable. Outer apply? Wassat? Absolute haram! Zzzzzz
>>107088204SQL is Turing complete, so you can write anything you want with it, but it will probably be painful to do it.
>>107088204No. It gets a bit more interesting with joins, subqueries, aggregate functions but that's about itYou should make the query more legible btw, it gets ugly fast
SQL is pretty simple and straight-forward as long as you're using it for simple, straight-forward data queries. But in the wild, you're going to run into SQL being used for things it absolutely should not be used for, and it gets fucking wild.
>>107088601geo functions?
>>107088420also triggers, temporary tables, even variables.you can do crazy shit in mysql if you go neck deep. thedailywtf often posts stuff where entire enterprises are managed via a 18 page long query.
>>107091270what have you done to the join to make it slow? OR in the clause? no keys?
>>107093160extensive use of of your database is good. you should lean into it as much as possible.I even often think that in-memory SQL databases are good to use when you are dealing with massively parallel operations and want transactions in order to handle them safely and elegantlyautomated indexes prevent you from needing to manually keep numerous data structures in sync
>>107092497this. SQL can be as complex as you want it to be.
>>107088204it does but it shouldn't for most uses
>>107088204Retard take.
>>107095125coreprotect stuff, pruning useless crap around farms and common arias so the database isnt 70GB
it seems slowly the business logic ends up in sql everywhere i work. how do i avoid it
I prefer raw SQL queries over frameworks that turn it into classes and objects.
>>107088204>Does it get much more complicated than this?It can get a little bit more complicated sometimes.https://excessivelyadequate.com/posts/matrix.html
>>107096475Use case for matrices in SQL?
>>107096497Making cool queries.
>>107096466ORMs are disgusting yesbut writing raw SQL strings is also retardeduse data structures to represent SQL, like in HoneySQLthis make dynamic queries and the composition of queries much easier and more refined
>>107096708Nobody is going to use shit like that in a professional setting fwiw
>>107088204Yes and no.Does it get more complicated in terms of writing out simple scripts to get data doing multiple joins ect ect ect? No, its just a matter of keeping track of it all.Does it get more complicated is doing the above but actually doing it effectively and not bogging down your system? Oh yeah, especially when you are dealing with applications that use SQL that was designed and written by people not good at SQL. The amount of times i have had to deal with moron that end up bringing databases to a screeching halt because of dog shit search's or selects is staggering. Building and making SQL databases and scripts is easy a shit, Making them good is hard. T. database engineer.
>>107096992anyone that has worked in "professional settings" knows exactly the kind of retarded shit you might run intohave fun duplicating a bunch of queries because your raw SQL does not support easy SQL composition>muh tables, stored procedures, etc.have fun adding massively to your workload when you need to do migrations
>>107092086>Sql doesnt really ever get complicated.You have no idea what kind of SQL some places use.
>>107097103views*
>>107092086as i said here >>107097039The basics are not complicated, but making a data base GOOD is a never ending game of issues.
>um it's just normal that queries take 3 minutes to hours. I honestly don't get why people use it to this day.The only answer I can come up with is sunken cost, baby duck, no academic interest and no funding for anything better. It objectively can't compose (best tools you have are CTEs or something like T-SQL or some procedural SQL), you literally cannot consistently format it and all the data "integrity" goes out the window once people start trying to fix their multi minute and multi hour queries with denormalizations and triggers that are a mockery of sql.I just worked on a problem today where a query was 10x faster just removing a join. I don't know what the answer is, but I look at graph DBs and they seem much more natural way to describe "relationships" than any RDBMS I ever used.And before some faggot says something retarded: dynamodb is very popular and isn't relational. Cassandra isn't, FoundationDB isn't.
>>107088204>Does it get much more complicated than this?Yes, but then you learn about ORM and realise you don't really need to know SQL at all.
>>107097289Forgot to throw in a shout-out how people get mad about integrity as well, but then shit up their data model with backdoors like synthetic keys as well. There is a good reason for them for some cases, I don't deny that, but it feels like yet another "hack" to work around the reality of your RDBMS being wrong for the job.
>>107097303you are much better off just learning the set-based nature of SQL than trying to shoehorn it into some retarded object system
>>107088204It can get a little gay when you need it to go fast so you have to structure the query in the right way. But it's nothing crazy.
>>107096708>he doesn't use Tera/Jinja with raw SQL files to generate Clorinde or SQLC queries for Rust/Go
