|
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
|
|
|
|
|
You just uncovered a deep truth. But shush, there are those who would burn you at the stake for casting light on the shadow of the arcane arts! ....
|
|
|
|
|
My next article will give SQL people fits, I'm sure.
Real programmers use butterflies
|
|
|
|
|
Unless it gives you the fits first.
Doing advanced string manipulation in SQL-Server is a sure sign of masochism.
|
|
|
|
|
That's why I'm writing a tool to generate SQL for the regex matching. I at least only have to write it once. =)
Real programmers use butterflies
|
|
|
|
|
In many cases you won't need to write it at all.
Oracle, Postgres, DB2 and even MySQL have full support for Regex. For the big ones it's basically SQL-Server that's the exception.
And for SQL-Server I wrote a CLR-function to take care of that. (REGEXP_INSTR, REGEXP_REPLACE and REGEXP_SUBSTR like on most other implementations)
And yes, you can write CLR also for Linux, since Linux work fine with .Net Core.
|
|
|
|
|
But can they tokenize? Most regular expression engines leave that out.
Also, is their regex a different flavor for every DB vendor? If so, they may as well not have it at all, because for real world regular expressions translating one form of one to another reliably is a bear.
The code is nasty. I've tried. It's honestly easier just to generate matching code that is consistent across platforms.
Real programmers use butterflies
|
|
|
|
|
|
It depends on what you are doing. For column validation in most cases you wouldn't need it.
However, if you intended to say, store chunks of JSON in your database (a surprisingly common practice these days) you could use a tokenizer (along with a parser generated by Norm targeting SQL) to validate or even normalize the JSON content so that invalid JSON does not get stored in the database but rather is rejected.
Typically this is done in the middleware, but such validation should in theory (where possible) take place in each of the "three tiers", which would include the database, for maximum assurance of data integrity..
Another use for it might be to allow you to search long structured text for particular things, like search an HTML document for all <B> tags and yield those as a table, which could be useful for things like CMS systems.
Real programmers use butterflies
|
|
|
|