Re: Inverting full names

VALUES ('Literature','30001f3d','John M. Doe','Doe, John M.');
[download]

You're trying to do what? You're trying to do put "John M. Doe" and "Doe, John M." into your database?

Not to be rude, but that's crazy.

You need to separate out the Doe, the John and the M and put them into one field each. How you do that is another problem, but that's not a sensible database design.

($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print

Comment on Re: Inverting full names Download Code

Replies are listed 'Best First'.
Re^2: Inverting full names by jhourcle (Prior) on Apr 09, 2005 at 12:16 UTC
Unless you know how the data is being used, it's impossible to know what is, or isn't a good database design. There are many times when denormalizing the data makes good sense, and when you wouldn't store the component parts. If they don't need to distinguish between the first and middle names, it's easier to just not bother with that step. If those two fields are used for sorting the records, and the database doesn't handle derived indexes, then it make sense to store the full version, possibly along with the name broken down into pieces. If they never need the name broken down into its component parts, (eg, they're only using it for display and/or sorting purposes), then they may not need to maintain them. Yes, they would have more flexibility in the future by storing it in terms of first/middle/last, but if you're tuning for reads, it's not efficient to put everything back together for every access. I personally thought that saying something wasn't sensible, and that something specifically needed to be done, without an intimate understanding of the reasons for its existance to be very rude.	[reply]

Replies are listed 'Best First'.

Re^2: Inverting full names
by jhourcle (Prior) on Apr 09, 2005 at 12:16 UTC

Unless you know how the data is being used, it's impossible to know what is, or isn't a good database design. There are many times when denormalizing the data makes good sense, and when you wouldn't store the component parts.

If they don't need to distinguish between the first and middle names, it's easier to just not bother with that step. If those two fields are used for sorting the records, and the database doesn't handle derived indexes, then it make sense to store the full version, possibly along with the name broken down into pieces. If they never need the name broken down into its component parts, (eg, they're only using it for display and/or sorting purposes), then they may not need to maintain them.

Yes, they would have more flexibility in the future by storing it in terms of first/middle/last, but if you're tuning for reads, it's not efficient to put everything back together for every access.

I personally thought that saying something wasn't sensible, and that something specifically needed to be done, without an intimate understanding of the reasons for its existance to be very rude.

[reply]