|
Usually, and usually just down to 3NF, but with "an eye" to avoid going too far or going that step further.
But very rarely these days do I get to do that sort of stuff - I'm stuck with what was someone else's idea of Good Database Structure. We disagree on what that looks like.
|
|
|
|
|
CHill60 wrote: I'm stuck with what was someone else's idea of Good Database Structure
That's why we normalize.
One of my "betters" once introduced a table that held a varchar(31) with 0's and 1's. Representing booleans. Queries where horrid and slow.
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: ntroduced a table that held a varchar(31) with 0's and 1's.
I had a colleague who used 1s and 8s -- because he couldn't get 0s to work correctly. 
modified 1-Nov-21 13:57pm.
|
|
|
|
|
This is why fights start in the office.
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 would if I could. 
In fact, I do as much as I can, which is limited and not always beneficial.
But the issue is that my current primary task is simply ETLing data from various sources to our staging database. For that, it's usually best to just leave it as is. But, at times, I do split some data into child tables -- usually if the incoming data has been de-normalized such that a field contains delimited lists of values (yuck).
It really depends on the needs of the next layer of the overall application, which often requires de-normalized data anyway.
On those rare occasions when I create a database for a "proper" application, I normalize as required for the application.
But I don't care about the definitions of the various normal forms; I leave that to the ivory tower types.
|
|
|
|
|
PIEBALDconsult wrote: But I don't care about the definitions of the various normal forms; I leave that to the ivory tower types.
They're not under debate in the tower.
The definitions didn't change. It's not C#.
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.
|
|
|
|
|
On the data entry / operational side, always; on the informational / query side, usually the opposite. Storage is cheap; time isn't.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
This about how to store.
No difference in entry or query.
Gerry Schmitz wrote: Storage is cheap; time isn't.
Time is not a factor here; this is about being correct. As in, making sure the data you return is correct.
It also not just applies to databases, but is general theory about information. Even applies to some lists, or dictionaries 
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.
|
|
|
|
|
Normally I do, yes. But not if I don't feel like it's going to be worth the hassle now vs benefits later.
|
|
|
|
|
How long is a piece of string - requirements would dictate NF compliance.
|
|
|
|
|
I've been coding for database interaction all my adult life - since the late 80s, and I've never heard of normalization so I looked it up and I'm aghast. How can you even use a database that isn't normalized? Why would you bother? Help me out here; where are these databases and what uses do people make of them?
|
|
|
|
|
Cpichols wrote: Help me out here; where are these databases and what uses do people make of them?
The sad answers to your questions are "everywhere" and "a mess".
Visualize a purchasing system where general customer information is free text. Further visualize trying to produce a sales report where a customer name may be spelled "ABC Trucking LLC", "ABC Trucking", "ABC Trucking Inc", and to make it really entertaining, " A B C Trucking " or " ABC Trucking" (application doesn't trim input and white space is significant).
On the plus side, working with a system like this will make anyone an expert in regex ... 
|
|
|
|
|
Okay then. While I do love a good regex puzzle, I'm thinking that maybe it's best to use selection menus built from a tight db. The db I work with was brilliantly designed, but does lack the level of normalization (ooh! look at me using this word in this new-for-me way! lol) that I would prefer, but it's pretty close for all that. I'd add one more layer, iah.
|
|
|
|
|
A wise man told me once: normalize till it hurts, then denormalize until it works.
My app are mostly transactional and I don't see any other way then to have denormalized data.
|
|
|
|
|
I usually do not unless it is specifically requested by the project/boss because I tend to favor performance over conformance to normalization.
To avoid data duplication or making a messy DB, I rely on my instinct and experience designing databases.
But my DBs (for production) are usually built in layers and normalization only applies to the bottom (data) layer. On top of that are usually performance layers like "history request cache" for each client, cached queries (for full/partial queries that are required by other queries, usually per client), filters for queries (usually temporary tables with partial data), etc.
And, before someone asks, yes those layers are implemented in the database (using SQL) where data is readily available and protected. And time is not wasted transferring data to some app while, in the process, creating a vulnerability in the database.
|
|
|
|
|
I almost always use third normal form to begin with and keep it that way unless there are performance problems.
|
|
|
|
|
During design, I normalize to the optimum end, the denormalize where necessary for performance. I've been following that process since I started in databases back in the late 80s.
Of equal importance is knowing what to index on, and how to keep indexing and PK-FK relationships from getting out of hand to where performance and supportability become a problem.
|
|
|
|
|
Monsters don't eat ghosts, because they taste like sheet.
|
|
|
|
|
That's a crap joke!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Halloween is the day that ordinary people dress up like people in the airport.
>64
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
I've heard the version with Walmart.
|
|
|
|
|
I thought it was Walmart.
|
|
|
|
|
Did you learn it from a first-hand experience?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
The way spirit is mixed with drug I gather. (6)
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
I feel like Structured Query Language was designed by someone who felt like everything should be *work* or it's not worth the effort.
The syntax is inexplicable. Not so much designed by committee as designed by a committee on a bender in 'Vegas. It's impossible to remember it without using it every day, and that possibility makes me want to bash my head bloody on the nearest hard surface.
Plus just doing simple things you'd be able to expect to do in other languages like type conversion or heaven forbid, string manipulation is like pulling teeth.
Now I know there are reasons for *some* of this, but most of it just seems like it was a result of throwing things at a wall to see what sticks.
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
