Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
There are so many programmers out there who are also an expert at Query writing and Database design.
Should this be a core requirement to be an expert programmer or software engineer?
Though there are lots of similarities in the way queries and codes are developed, my personal opinion is, Queries seem to have a different Structure than Code and it can be tough to Master both simultaneously due to the different approaches.
Whether or not database query writing should be a core requirement depends on the job, but relational databases are ubiquitous in current technology.
So, if I met a programmer that didn't know how to write database queries, I would expect one of two things:
Database queries are fundamentally different from more standard programming languages. They are algebraic and intended to operate on relational data, while C# or Java are imperative and operate on disks, memory, user input, etc. Even functional languages like LISP or Haskell that are more algebraic in form are less oriented to relational data.
EDIT: As has been pointed out in the comments by me and others, there are some valid reasons why an experienced developer may not know database queries well:
Though valid, these caveats are not convincing reasons why an experienced developer would not know database queries. Unless highly specialized, a programmer should be familiar with relational databases.
In summary, most experienced developers should know database queries.
Any software engineer should have a basic understanding of databases and how to store and retrieve data using SQL, at least to the level where they have an understanding of what this can be used for (and with that I would include an understanding of keys, views, stored procedures and triggers).
Not every software engineer needs to be an expert, and the level of expertise required really depends on the type of software they focus on. Embedded software, hardware drivers and operating systems rarely use SQL, but application software (be it web or desktop or service/daemon based) use databases all the time.
There are some areas of expertise (embedded systems for example) where database knowledge is not needed. But most business applications use a database of some kind and if you don't thoroughly understand how to use it properly, you can create a performance mess that is extremely difficult to fix. Refactoring databases can be a complex and difficult process and many places opt not to fix the structural problems because of that difficulty and just dig themselves deeper into a hole. If you have database knowledge, design is much easier and far more likely to work well over time.
ORMs are not a substitute for getting database knowlege. Anyone who uses one without knowing the basics of database querying and design is doomed to havea poorly performing, badly designed database which will affect the long range abilty of your application to handle the load. ORMs in the hands of someone who knows what he or she is doing are fine; in the hands of people who can't be bothered to learn about databases, they are usually a disaster.
If I had a project with a database backend, the database specialist would be the second developer I would hire (after the intial application developer). Databases are generally not throwaways, that data will still be there in close to the same form 20 years later, it pays to have expertise in the beginning stages.
Projects often get into trouble because they don't hire these people until the database has 100,000,000 records and is running slowly. Or they blame the tool for being bad (no SQL Server is not slow if you design correctly) not their design incompetence.
The politically correct answer: It depends. SQL knowledge has no value whatsoever if the developer never works with relational databases (and in this day and age of NoSQL applications, that's actually quite likely).
Second, when there's a DBA or full-time query writer (whatever the title is), then understanding is also of lesser importance.
It's only really important if the developer needs to be a jack-of-all-trades and there's a requirement in his projects for using a relational database (for example in old-fashioned web applications or connecting with existing databases)
My personal opinion: No. An experienced software developer should be able to learn a new skill (such as SQL) if and when they need to, not 'by default'. Flexibility and the ability to learn and understand is, imho, what differentiates a good developer from an okay one. The 'golden hammer' rule also applies - if you have a developer with extensive SQL knowledge, it's very likely this developer will pull out the tool he knows best - relational databases - to attempt to solve every problem, whilst it doesn't necessarily have to be the best solution. Of course, this also applies to NoSQL advocates, ;).
Picking the right tool for the right job is what an experienced programmer should know.
Check out this wikipedia introduction to Computer Programming:
Computer programming (often shortened to programming or coding) is the process of designing, writing, testing, debugging / troubleshooting, and maintaining the source code of computer programs. This source code is written in a programming language. The purpose of programming is to create a program that exhibits a certain desired behavior.
Database queries has their own languages , they could be designed, tested , debbuged and mantained. The purpouse of a database query is to allow you to obtain the information you need, the way you need it.
So i think that it is programming, definitly.
A good software engineer with a background in enterprise and business applications (EDIT: specifically in projects that utilize an RDBMS) should have expert knowledge of writing relational database queries in the standard format. Further they should be able to understand complex schema and propose schema designs of at least moderate complexity.
Extremely advanced or complicated schema design should be the realm of a data modeler or functional architect.
This doesn't mean that Database Programmers don't have a place either. Complex stored procedures, complex and efficient queries and database tier software design and architecture focused on the unique tools and offerings of a single database vendor (Eg. Oracle, MySQL, SQLServer, etc...) should be best left when possible to professional software engineers who have experience with these highly specialized and complicated offerrings.
The vast majority of business and enterprise systems however in my opinion don't justify the need for data modelers and specialized database programmers but I have worked on such projects before that GREATLY benefited from the knowledge and expertise that these people brought to the table.
Others have already answered your question about database queries.
Database design is a particular type of design. It's not that hard to learn, but the typical database designer doesn't get that many opportunities to design a database.
The place I'm working now has the same database design that it had in 1970. We've moved the database from IDMS to DB2, but it's the same network database design. I have had the opportunity to create 5 new DB2 tables in the 9 years I've worked here.
I suspect that there are very few work places with a dedicated database designer. So, I'd conclude that database design is considered part of the repertoire of a senior analyst.
I'm quite frankly amazed that so many of us think that every development revolves around a database, and an SQL database at that.
Others have mentioned the many ways in which we can avoid the nitty-gritty of SQL in our jobs, even when we are working (indirectly) with databases, but what about all the developers that write the firmware for the 101 electrical products the we each possess? What about the guys specializing in real-time monitoring?
I would suggest that the majority of today's developers will have SQL skills to varying degree, but it is far from being a barometer of their ability.
I think you overestimate the importance of databases in software.
Many classes of application are not database-centric.
Do we need a DBMS in word processors and image editors now? What about speech recognition and computer vision systems do these contain a lot of database queries?
And what of linear video editors and video game physic engines?
I would expect a generalist developer to have at least an awareness of database technologies (relational or otherwise) and be able to discuss the pros and cons of using them. Otherwise, I'd be afraid all they know how to do is stuff data into flat files.
I don't think query writing should be a core requirement for programmers. Having said that, I believe that a programmer who can write queries and design databases would be more valuable to an organization.
However, if this programmer can only write "select * from tblxxxx" type queries I would not consider this programmer to be an expert. Likewise, if the database designed by this programmer places one-to-many relationships into one table instead of two tables then I would not consider this programmer to be an expert.
Here's how I explain this to non IT people. IT professionals specialize in certain areas similar to how carpenters, electricians and plumbers specialize in there respected fields. They tend to overlap some of the skills but are not experts in all areas. An electrician can do simple carpentry tasks with confidence but would not bode well trying to tackle complex structures.
Likewise, a programmer can and should know how to write or manipulate simple queries and database designs but not be expected to design a complex data structure.
Looking around in our department, it depends:
