#Database
when to use code vs when to use sql

Just recently I spent a few hours attempting to make an overly complex SQL query into a reality. From the beginning, it didn't really feel right. The data was slightly off, and there was this nagging feeling hovering that it wasn't going to end well. It wasn't that the query itself was complex. But more that the data wasn't very well stored, formatted and queryable. But nonetheless, because I began to solve it with a data-based mentality and because I had dedicated so much time on a query that would take years to describe I decided to continue the relentless battle. At the end, I ended up with a query that would be forgotten within a 15 minute timespan and with a dataset that might or might not be correct. There was very little I could do to verify whether a 2 paragraph query was valid or not.

. . .
Continue reading
2
database normalization is good and bad

Every developer does it subconsciously nowadays. We create a database schema and we normalize it without thinking about it. At least I hope we do. We let the data speak for itself. Sometimes that doesn't turn out so well, and sometimes it isn't terrible. There are several goals when designing a database that I try to keep in mind. A few include reducing the amount of duplicate data, making the data clear and readable and reducing the number of changes needed to the code whenever new data sets are introduced. It's always nice coming back to an old project and having it make sense without having to relearn how it works.

Database Normalization is . . .

Continue reading
"sometimes you have to delete, to find your answer"
Copyright © 2018 thatsoftwaredude.com
humans.txt
TOP SCORES
Score in the top 10 and leave your Instagram handle.
Start
0
snake left
snake up
snake down
snake right