When it comes to software, I am a belt, suspenders, and two pairs of pants type of person. Everybody makes mistakes sometime, and assuming that the other person was supposed to handle it is a recipe for disaster.
I had a case where a large number of records with information on cases contained NULL in the case identifier. The person responsible for that code didn't believe me and told me to prove it by providing ten examples. I gave him a list of four hundred cases. I had the report on my desk and the reason the number was so low was that the SQL query was limited to 400 cases. The response of the database administrator was that he had only asked for ten cases, and he thought that I was trying to embarrass him by listing so manycases. What you need to do is insert the constraints and review all the errors it picks up.
In another case, there was a web page on LinkedIn that didn't work. Many people were unable reorder interest groups on the profile page. People were complaining loudly on several social media sites. Requests to the help desk received the following message: "We are giving top priority and will notify you when a solution is found." I examined the code for the page and determined that the servlet was using two SQL statements: one had an inner join and the other had an outer join. They were joining the two result sets by row number. I notified the help desk and had them validate it by fixing the problem with my profile using the help desk's interface with the database. I wrote this up and sent it to the help desk who repeated the previous request. I asked them to reread my email, and they said that they were sorry for not reading it. The person also said that they had been told to give the above response and ignore it.
If you really want to do a good job, you have to be willing to look for things that make you look bad. Most people don't want to do that, and the managers tend to be worse.
You have to assume that other portions of the system may contain errors.
If you check for errors in other programs, the ability of other programs to totally corrupt the database is limited.
The optimizing routines for the DBMS are designed to use the constraints to run faster. More constraints mean that more information about the data is available, and better optimizations are possible.
Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
Thank you for your insights, and I think I recognize your angle. Your examples really highlight the benefits of using a database's powerful tools. I'll reflect back that where I find the most productive fun is one where there is no need for a database administrator. I don't say to invalidate your context but rather to highlight the wonderful differences there are between our contexts.
I'm reminded of this scene from the movie Contact, where sometimes letting go of the seatbelt results in a smoother ride 😅, and I recognize you could just as well link to a car-crash where we'd agree seatbelts really are useful.
I enjoyed reading your angle because it illuminates the wonderfully different contexts we all find ourselves in, and thanks for reading the article.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When it comes to software, I am a belt, suspenders, and two pairs of pants type of person. Everybody makes mistakes sometime, and assuming that the other person was supposed to handle it is a recipe for disaster.
I had a case where a large number of records with information on cases contained NULL in the case identifier. The person responsible for that code didn't believe me and told me to prove it by providing ten examples. I gave him a list of four hundred cases. I had the report on my desk and the reason the number was so low was that the SQL query was limited to 400 cases. The response of the database administrator was that he had only asked for ten cases, and he thought that I was trying to embarrass him by listing so many
cases. What you need to do is insert the constraints and review all the errors it picks up.In another case, there was a web page on LinkedIn that didn't work. Many people were unable reorder interest groups on the profile page. People were complaining loudly on several social media sites. Requests to the help desk received the following message: "We are giving top priority and will notify you when a solution is found." I examined the code for the page and determined that the servlet was using two SQL statements: one had an inner join and the other had an outer join. They were joining the two result sets by row number. I notified the help desk and had them validate it by fixing the problem with my profile using the help desk's interface with the database. I wrote this up and sent it to the help desk who repeated the previous request. I asked them to reread my email, and they said that they were sorry for not reading it. The person also said that they had been told to give the above response and ignore it.
If you really want to do a good job, you have to be willing to look for things that make you look bad. Most people don't want to do that, and the managers tend to be worse.
Hi Bradley,
Thank you for your insights, and I think I recognize your angle. Your examples really highlight the benefits of using a database's powerful tools. I'll reflect back that where I find the most productive fun is one where there is no need for a database administrator. I don't say to invalidate your context but rather to highlight the wonderful differences there are between our contexts.
I'm reminded of this scene from the movie Contact, where sometimes letting go of the seatbelt results in a smoother ride 😅, and I recognize you could just as well link to a car-crash where we'd agree seatbelts really are useful.
I enjoyed reading your angle because it illuminates the wonderfully different contexts we all find ourselves in, and thanks for reading the article.