|
Jörgen Andersson wrote: But you should probably have asked to what form.
If I need to ask that, then the answer is that there's usually no normalization.
Jörgen Andersson wrote: I personally go for at least third, but usually not up to fifth. It depends on purpose.
So it depends on purpose? 
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yes, but usually no further than third level. For really small databases the answer is usually not, especially if I inherited the structure.
|
|
|
|
|
I normalize until 3rd NF.
Maybe I'll have some denormalized tables for quick access. But I only do that when performance is not good, and I can't find another problem. That is, no premature optimizations.
|
|
|
|
|
Looking it up (i had to) it looks like I typically use 3NF.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Looking it up (i had to)
You'd do it on instinct, with butterflies 
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I do. That's why I had to look it up. I never learned it formally. I just learned "construct a database in a way that maintains integrity and is sane enough for the application to survive for awhile"
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I do. That's why I had to look it up. I never learned it formally.
It does sound like I'm attacking. My apologies.
honey the codewitch wrote: construct a database in a way that maintains integrity
You'd laugh and go "that's soo obvious".
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I didn't take it as an attack, no worries. I figured I just needed to clarify.
I learned DBs in the .com boom days when it was a free for all. I attempted to impose some order on the mess. All I got for my efforts typically was put in charge of databases - something i didn't want to be in charge of.
And then there was the time when I worked with a self taught developer who built out an entire ecommerce platform, front and back end, including a jquery-like (but *not jquery   ) engine for the front end. Rather than doing JOINs in the database he was doing them in PHP on the webserver.
I taught him SQL. Then I quit.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Rather than doing JOINs in the database he was doing them in PHP on the webserver
I had a colleague like that once. He was transferring two 100G entries tables (+-50 columns each) to PHP to do joins using for loops. It was killing the server and taking almost a week to process.
The boss only noticed when he requested a new, more powerful server (our server was brand new). Boss told me to converted it to SQL and it started taking less than an hour to do the same join 
That colleague quit the project soon after that.
|
|
|
|
|
ElectronProgrammer wrote: That colleague quit the project soon after that.
Did he fall, or was he pushed? 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
He fell. It wasn't his only mistake. I tried to give him an hand but he took the arm to harm (he had a PhD and I had a licenciate degree*). I would rather have him there than ending overworked and underpaid as I did. I guess the corporate reality train was to heavy for him 
* That degree is one below masters and one above bachelor in pre-bologna process which was my case
|
|
|
|
|
About five+ years back I normalized the hell out of databases, but I've come to realize a surprising amount of data needs to be stored redunantly anyway.
Stuff like customer names and addresses on invoices, sales people's names on orders, etc.
In the age of microservices every service needs to have the data it needs to do its thing.
So I now even have multiple databases with the same data because multiple services operate on that data.
Although I usually normalize my services as well... 
|
|
|
|
|
That's true, and given the amount of space to work with that we have these days, and how good databases are at doing batch data conversion and such, there really isn't a good reason to avoid redundant data if it makes things easier or more efficient. You just have to be careful not to go crazy with it, and you have to keep in mind that it can make your database more "brittle" because its more fields that need to be proofed/validated for correctness. Keeping redundant data in sync is a chore unto itself.
But yes yes yes to this. Redundant data is okay, when it serves a purpose, often for performance or integration purposes it is The Right Way(TM) to do things.
And if I'm wrong then I got paid a whole lot of money to be wrong, and a lot of people happy with how wrong I was. 
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: The Right Way(TM) to do things.
Math.
honey the codewitch wrote: And if I'm wrong then I got paid a whole lot of money to be wrong
Yeah. Happy my surgeon isn't like that 
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Math.
NoMATH (for clarity, Not Only Math) 
Actually, that math was failing with big enough datasets, which is why NoSQL was (re-)invented.
So the right way to do things went from "normalize everything" to "denormalize a good bunch."
We've seen the opposite happen to peanut butter.
|
|
|
|
|
I find No SQL kind of funny as it is one of those cyclic patterns.
In the same vein with centralized versus distributed.
|
|
|
|
|
Before SQL, which didn't become popular until the 80's, there was only not SQL
|
|
|
|
|
But don't forget what Edsger Dijstra once said: If you say the same thing twice, you will contradict yourself.
|
|
|
|
|
Not if you say it properly. *hides*
Real programmers use butterflies
|
|
|
|
|
When you're talking about redundant storage, are you referring to data aggregated from single points of origin or an uncontrolled mess?
|
|
|
|
|
Why not both?
But seriously, what starts out as the first sometimes turns into the latter 
Mostly the first though
|
|
|
|
|
And some redundancy is not really redundant, it is the historical context that needs to be saved.
The invoice earlier is a good example.
If the company changes its name or moves it’s HQ, you do not want the invoice to update.
The best part is when there are M/A and divestitures among your client base.
At a high enough altitude, it looks like a game of Life cellular generational display.
|
|
|
|
|
Sander Rossel wrote: In the age of microservices every service needs to have the data it needs to do its thing.
Good point, those use a smaller dataset.
Sander Rossel wrote: So I now even have multiple databases with the same data because multiple services operate on that data.
Operating implies you doin' more than reading that data.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Operating implies you doin' more than reading that data.
It's mostly reading and transforming.
Not like, changing the data and then posting it back to its origin or something like that, that would be chaos.
|
|
|
|
|
What if my databases are abnormal?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
