4 ms·

But the same is true of any other language. Given a complex piece of C++, no amount of IDE features is going to help anyone understand it, nor know what is impl

But the same is true of any other language. Given a complex piece of C++, no amount of IDE features is going to help anyone understand it, nor know what is implications could be in a system (without looking at the entire source code to see where it is used). What you are lacking is: a) knowledge of your chosen database system in sufficient detail to know the trade-offs and pros/cons, and b) sufficient knowledge of SQL specific to your chosen database system in order to get the most out of it. This is a bit like knowing C++ in sufficient detail to be able to cope with a complex bit of code that you see, and also knowing your compiler sufficiently well so that you know it has foibles/bugs in certain areas. What you need is more knowledge, not more tools. Even if I have a hammer and a chainsaw, both are useless to me if I don't know enough about wood to build what I want.

maxxxxx 10y ago
You are right. At least for me the problem is that I don't have enough time to spend on dealing with the database. There are a ton of other components in the system that need attention so there is not enough time for SQL in depth. And yes, the tooling could improve a lot. Source control is a pain. Some query analyzers that explain the execution path would help. Refactoring tools would be good. Better stored procedure syntax would be nice. Technically SQL databases are miracles in performance but to me they are simply not accessible enough.
- 72deluxe 10y ago
  I used to write a lot of SQL but now not so much so I am in the same situation where I forget everything. I suppose the only way to keep proficient in any of the languages we learn is to keep using them, either through a side project (if we have time) or in our main job. I try and keep time set aside to read and keep up to date on languages etc. I think just immersing yourself in your database and trying to solve problems with it, combined with reading of documentation is the only way to improve. Out of interest, what database system are you using?
  - maxxxxx 10y ago
    MS SQL Server and Mongodb at the moment. Have used SQLite and Oracle before. My problem is that the the database is only a very small part of the system and doesn't integrate well. I simply don't have time to immerse myself. I have done this several times before and after a while I just forget. Not the principles but the syntax. We just had a need for a huge transformation. Someone wrote it in C# procedurally and it was super slow. I told him to try pure SQL and it was super fast. Really impressive. But the code is just super cryptic to most programmers and hard to maintain. And as I said before source control sucks.
    - 72deluxe 10y ago
      SQL Server is excellent, truly excellent. You have a bunch of excellent tools there with the profiler, query analyser and management studio in general. SQLite is good fun for embedded stuff. C# being slow with a DB sounds like someone was doing a load of processing in the application instead of in the database? eg. grabbing a load of data with a simple SQL query and then doing all the processing in C#?? I have come across that before with someone who knew very little SQL and it's embarrassing to see. For the pure SQL, get the guy to add comments and put it in TFS (or whatever your version control system is). That might help. If it is super cryptic to most programmers, get them to educate themselves! All code looks cryptic if you're not used to it.

maxxxxx 10y ago

You are right. At least for me the problem is that I don't have enough time to spend on dealing with the database. There are a ton of other components in the system that need attention so there is not enough time for SQL in depth. And yes, the tooling could improve a lot. Source control is a pain. Some query analyzers that explain the execution path would help. Refactoring tools would be good. Better stored procedure syntax would be nice. Technically SQL databases are miracles in performance but to me they are simply not accessible enough.

72deluxe 10y ago
I used to write a lot of SQL but now not so much so I am in the same situation where I forget everything. I suppose the only way to keep proficient in any of the languages we learn is to keep using them, either through a side project (if we have time) or in our main job. I try and keep time set aside to read and keep up to date on languages etc. I think just immersing yourself in your database and trying to solve problems with it, combined with reading of documentation is the only way to improve. Out of interest, what database system are you using?
- maxxxxx 10y ago
  MS SQL Server and Mongodb at the moment. Have used SQLite and Oracle before. My problem is that the the database is only a very small part of the system and doesn't integrate well. I simply don't have time to immerse myself. I have done this several times before and after a while I just forget. Not the principles but the syntax. We just had a need for a huge transformation. Someone wrote it in C# procedurally and it was super slow. I told him to try pure SQL and it was super fast. Really impressive. But the code is just super cryptic to most programmers and hard to maintain. And as I said before source control sucks.
  - 72deluxe 10y ago
    SQL Server is excellent, truly excellent. You have a bunch of excellent tools there with the profiler, query analyser and management studio in general. SQLite is good fun for embedded stuff. C# being slow with a DB sounds like someone was doing a load of processing in the application instead of in the database? eg. grabbing a load of data with a simple SQL query and then doing all the processing in C#?? I have come across that before with someone who knew very little SQL and it's embarrassing to see. For the pure SQL, get the guy to add comments and put it in TFS (or whatever your version control system is). That might help. If it is super cryptic to most programmers, get them to educate themselves! All code looks cryptic if you're not used to it.