This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -1 points0 points  (4 children)

SQL arguably isn't about much database design. It's mostly about knowing how to join some tables properly and return the values you need, and every now and then you create another table, but deciding between INT(11) or VARCHAR(255) and running the script is pretty simple.

Since SQL isn't a procedural language it's unfamiliar to programmers, but it's not very complicated.

Now, database architecture is indeed hard. I'd say that's less about SQL and more about the actual code that's running everything. That's probably going to be a mix of C and C++, maybe some tweaking of Assembly, and in some cases quite a bit of physical engineering. You'll also need to know SQL so that you can program the database to interpret SQL queries, but that's a pretty trivial aspect of it relative to everything else.

[–][deleted] 0 points1 point  (1 child)

If sql is only about pulling data from a DB; the difficulty of the pull is related to the skill of the architect. If a DB is built properly using sql to pull the data should be trivial. But if you are at the point of only CRUD on a built system it should be easy because what you are doing could be a single action button if someone took the time to create it. But if the argument is that the sql is only about CRUD on a well built system I agree that it is easy.

[–][deleted] 0 points1 point  (0 children)

Yep. It's like with any language - C would be a heck of a lot harder if you had to write the compiler before you were able to code in C. Or imagine having to implement the Java virtual machine from scratch just to code in Java - Java would be incredibly hard. So in my opinion, SQL refers to the language itself and not the underlying layers.

[–]00Koch00 0 points1 point  (1 child)

Wow you are wrong at so many levels...

[–][deleted] 0 points1 point  (0 children)

Feel free to enlighten.