Hyphenated Name Field

I have designed databases but have never come across any complications due
to the ridiculous situation of a hyphenated last name. As a database
designer (very junior level) I disdain anything unwieldly, and consider this
unwieldly.

I haven't dealt with it, as I said, but I figure if I do, I'd simply design
the text field to not accept hyphens, so Smith-Barney would be stored as
SmithBarney, or even Smithbarney as I commonly have the forms automatically
apply a Title Case to everything entered.

It is standard practice in many databases to leave such characters out, in
phone numbers for example even when an "input mask" is designed and it's
prompting you how to do everything and it asks you if you want to store the
hyphens the default is that it doesn't. This seems to be the smarter way to
go, as it prevents formatting pecularities from messing up searching &
sorting etc.

Is this how Smith-Barney should be dealt with--prevent the hyphen? Or would
feminazist-clients become too upset?

PS--this is NOT a troll message, not trying to upset anyone--again, I have
designed databases and am asking as such, as I have never come across this
yet but figure one day I will

LRH

re: Hyphenated Name Field

On Thu, 26 May 2005 22:39:09 -0700, "Larry R Harrison Jr"
<noone@noone.com> wrote:

I prefer to deal with field values as they are. If that means writing
extra code to handle Smith-Barney or O'Brien, so be it.
Masks is a different situation. You can store them, or not. Just be
consistent.

-Tom.

[color=blue]
>I have designed databases but have never come across any complications due
>to the ridiculous situation of a hyphenated last name. As a database
>designer (very junior level) I disdain anything unwieldly, and consider this
>unwieldly.
>
>I haven't dealt with it, as I said, but I figure if I do, I'd simply design
>the text field to not accept hyphens, so Smith-Barney would be stored as
>SmithBarney, or even Smithbarney as I commonly have the forms automatically
>apply a Title Case to everything entered.
>
>It is standard practice in many databases to leave such characters out, in
>phone numbers for example even when an "input mask" is designed and it's
>prompting you how to do everything and it asks you if you want to store the
>hyphens the default is that it doesn't. This seems to be the smarter way to
>go, as it prevents formatting pecularities from messing up searching &
>sorting etc.
>
>Is this how Smith-Barney should be dealt with--prevent the hyphen? Or would
>feminazist-clients become too upset?
>
>PS--this is NOT a troll message, not trying to upset anyone--again, I have
>designed databases and am asking as such, as I have never come across this
>yet but figure one day I will
>
>LRH
>[/color]

re: Hyphenated Name Field

On Thu, 26 May 2005 22:39:09 -0700, Larry R Harrison Jr wrote:
[color=blue]
> I have designed databases but have never come across any complications due
> to the ridiculous situation of a hyphenated last name. As a database
> designer (very junior level) I disdain anything unwieldly, and consider this
> unwieldly.
>
> I haven't dealt with it, as I said, but I figure if I do, I'd simply design
> the text field to not accept hyphens, so Smith-Barney would be stored as
> SmithBarney, or even Smithbarney as I commonly have the forms automatically
> apply a Title Case to everything entered.
>
> It is standard practice in many databases to leave such characters out, in
> phone numbers for example even when an "input mask" is designed and it's
> prompting you how to do everything and it asks you if you want to store the
> hyphens the default is that it doesn't. This seems to be the smarter way to
> go, as it prevents formatting pecularities from messing up searching &
> sorting etc.
>
> Is this how Smith-Barney should be dealt with--prevent the hyphen? Or would
> feminazist-clients become too upset?
>
> PS--this is NOT a troll message, not trying to upset anyone--again, I have
> designed databases and am asking as such, as I have never come across this
> yet but figure one day I will
>
> LRH[/color]

Personally, I think it's disrespectful to a person to write his/her
name as anything other than the way that person want's to see it.
Smithbarney is not the same as Smith-Barney. If I was Mr. Smith-Barney
and received a letter with my name improperly spelled like that I
would not be favorably inclined towards whatever the letter was about.

You state that you are using 'Title Case' (StrConv I assume).
Are you concerned with names like O'Brien and Smith-Barney being
improperly capitalized as O'brien and Smith-barney?
It's no problem to write a User Defined function to check for a hyphen
within a name and capitalize the next character if that is your
concern. A table of name exceptions does well with names like
O'Brien (as well as McDonald and van den Steen).

--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.

re: Hyphenated Name Field

I have a problem having to write code specifically for this special
situation, when all other names don't need it. Why should code have to
be written for such specific situations--code which will only add bloat
and complexity?

Databases work best when data goes where it is supposed to--and
conforms to a certain standard. That's why so many systems make you not
enter hyphens, or extra spaces, or enter the first name in the first
name field as opposed to your middle name there because you like going
by your middle name rather than 1st name. If everyone would just do
things the same way, you wouldn't have to program for the
complexity--and I like how things like government forms don't
accomodate and make people who go by their middle name--say "Larry
Reynolds Harrison" goes by Reynolds--they nonetheless fill out "Larry R
Harrison" just the same--they don't accomodate for the special
circumstance because it adds too much complexity, those exceptions
shouldn't compromise or complicate the other data.

Trust me, I don't have an attitude towards personal preferences--as
long as they don't add special complications that 95% of other
situtaions don't. Why should someone think they're so special by having
a hyphenated name that an entire database & its system has to be
altered to accomodate them when everyone else's normal situations don't
require this? That is what I have the problem with--and I kind of like
systems which don't. Maybe I'm sick, I don't know--I know that those
who design databases are there to help & not hinder, but you kind of
need the cooperation of the client to not bend things too much to help
towards this end.

LRH

re: Hyphenated Name Field

larrytucaz@yahoo.com wrote:[color=blue]
> I have a problem having to write code specifically for this special
> situation, when all other names don't need it. Why should code have to
> be written for such specific situations--code which will only add bloat
> and complexity?[/color]

I agree with Tom van Stiphout and fredg. Hyphenated last names were
not invented to frustrate programmers. They are real data. If the
strConv function can't handle capitalization of the real data then you
have to find another way to make it happen. Trying to apply political
pressure to persuade the client into accepting something that is not
real data because you can't handle the complexity is backwards IMO.
[color=blue]
> systems which don't. Maybe I'm sick, I don't know--I know that those
> who design databases are there to help & not hinder, but you kind of
> need the cooperation of the client to not bend things too much to help
> towards this end.[/color]

So is the thinking that the client would be bending things by asking
that this situation be handled.

James A. Fortune

re: Hyphenated Name Field

On 1 Jun 2005 11:21:33 -0700, larrytucaz@yahoo.com wrote:
[color=blue]
>I have a problem having to write code specifically for this special
>situation, when all other names don't need it. Why should code have to
>be written for such specific situations--code which will only add bloat
>and complexity?
>[/color]
Big Snip[color=blue]
>[/color]
I may be at the other end of the spectrum. I don't try to make any
one-size-fits-all formatting rules for text fields. If the data entry person
enters the first character as lower case for a proper name, it stays lower
case. On the other hand, if the first character after a hyphen is capitalized,
it stays that way too. I don't think it is too much too ask that the data
entry person use proper grammatical rules. So far, at least, it's not against
the law to think about what you are doing at your job.

Just a wizard prodder
Chuck
--

re: Hyphenated Name Field

<jimfortune@compumarc.com> wrote in message
news:1117652710.438237.260330@f14g2000cwb.googlegr oups.com...
[color=blue]
> So is the thinking that the client would be bending things by asking
> that this situation be handled.
>
> James A. Fortune
>[/color]
In some cases, absolutely. For example, I have actually had persons before
wonder how come their attempts to enter data crashed when they tried to
enter the state in the Zip code. They enter some names as "O'Brien" and
others as "OBrien" and still others as "O Brien"--only to then wonder why
not all of those are sorted together as if they're the same. They wonder how
come a query they later add themselves for showing "O'Brien" returns
inaccurate numbers because of the other variations entered.

Duh! You have to be consistent, enter them all the same way.

Then of course you have drop-down lists for states commonly, because some
will enter "NC" some "N.C." some "nc" and on and on. You have to be
consistent, else search results and the like will be off. You wouldn't
expect me to design the query to say "NC" or "nc" or "n.c." or "N C" or "Nc"
and on & on, would you? I would surely hope not.

Simply enough--with data, you have to have consistency with such things. It
would be ridiculous to ask a designer to allow for these variations. What I
will do instead--and others apparently do likewise--is design the database
to FORCE the user to enter all such entries identically. Not sure how one
would do this with the O'Brien issue--unless they made it unable to accept
the ' character or spaces of any kind--but with states, again, commonly a
drop-down list of states would be attached to the "state" field, with the
"limit to list" attribute set to "yes."

To me, this is such a situation. If you have some who would call themselves
"Smith Barney," others who would call themselves "Smith-Barney" others who
would have some other variation--you end up complicating things. If you
search for those whose true last name is "Barney," for instance, you may
pull up "Smith-Barney" in there as well undesirably--if you are doing one of
those "Like "*" And [name] and "*" type of searches.

Simply enough, it adds complexity where it isn't needed. I think that is
why, for instance, I hear that when my brother in law who I shall call "John
George Smith"--we likes to go by George rather than John--he has to enter
forms "John G Smith," because they ask for his middle initial ONLY, they do
not care what his middle name is, even though that's what he goes by. To
MAKE SURE he gets found in important searches, they make him along with
everyone else enter his first name in full, his middle initial ONLY, then
his last name--period. No exceptions, whatsoever. I would guess if his last
name was "Jones-Barney" they would have him fill out the form "JonesBarney"
and that's how it would get entered.

I like such designs, personally. And I figure--I don't know, but if people
like "George" can be understanding of such realities with government forms &
the databases that hold the data, why should we do any differently? The
conformity is a GOOD thing--increases the probability of the data being
obtained properly and quickly, and helps prevents "cross contamination" of
data with similar names. In other words--data integrity. Isn't that the
point? If overly-sensitive types are wanting to compromise this to save
their sensibilities, I say they need a reality check.

In closing--I typically post here with extremely practical questions, not
opiniated ones. I typically ask questions like "what syntax is appropriate
for creating a joint query in SQL." I will make sure to stick to such
questions in the future for the most part and hopefully not waste anyone's
time here; I realize Microsoft MVPs and the like are hanging out here to
help & don't want to get sucked into long-winded opinion discussions. I am
asking as a designer, not trying to be opiniated politically so much as that
the objective here is the protection of data integrity, not sucking up to
people's whimsical fascination with titles & so forth.

LRH

re: Hyphenated Name Field

I do hear you. Sometimes giving a certain field "room" to be "loose" may be
the way to go. I know that recently I was actually a data-entry clerk at a
job assignment but I designed a form which converted what I entered to title
case--and it very significantly increased my speed.

I think maybe an unbound check box which, if checked, does NOT execute the
StrConv function in the name field, could be utilized as an override option;
if not checked, the last name would be converted, if checked, it would not
be. It could have an &h caption or something so the data-entry person could
type ALT-H to toggle this switch off & on without having to use the mouse &
slow his/her data-entry down.

LRH

re: Hyphenated Name Field

Larry R Harrison Jr wrote:
[color=blue]
> I think maybe an unbound check box which, if checked, does NOT execute the
> StrConv function in the name field, could be utilized as an override option;
> if not checked, the last name would be converted, if checked, it would not[/color]

If you've data entry experience as you say, then you'll know anything
optional is always forgotten by data entry clerks.

Go with Chuck's method. Some data entry people may be misogynist as you
demonstrated in your OP, but most are not stupid.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

re: Hyphenated Name Field

"Tim Marshall" <TIMMY!@PurplePandaChasers.Moertherium> wrote in message
news:d7lalf$bh7$1@coranto.ucs.mun.ca...
[color=blue]
> Go with Chuck's method. Some data entry people may be misogynist as you
> demonstrated in your OP, but most are not stupid.
> --[/color]
As I said to Chuck, his way (which is, anything goes in such fields) may
well be the way. It is a delicate balance between controlling how the data
are input so as to keep it "normalized," vs giving flexibility so that
what's needed to be entered can be. That said, the misogynist label doesn't
apply. I don't hate women, I hate strays from the norm which complicate
things, whichever gender is the one doing it. Gender is irrelevant.
Conformity and data-integrity are what matter, not feelings.

LRH

re: Hyphenated Name Field

Larry R Harrison Jr wrote:
[color=blue]
> I hate strays from the norm which complicate
> things,[/color]

And that's what you will always have to contend with as a DB developer.

8)

Be prepared for furrowed foreheads of clients who are upset when they
discover a miniscule fraction of data is not dealt with. Those clients
will view such an app as garbage and will be unable to appreciate the
work and elegance you may have driven yourself into the ground to
provide... just because of that small fraction. Been there, done that. 8(
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

re: Hyphenated Name Field

Thanks for the heads-up. It does sound like something I'd encounter. I can
see it now--people flipping out because they try to enter "piou0" in the ZIP
CODE field and expecting it will magically recognize it as valid & process
it somehow.

I did have something happen a few years ago, when I designed a database to
import data from an Excel sheet but then it couldn't because the data came
"un-normalized," I basically would've had to "dumb down" my design to import
his data. It would have resulted in un-normalized data, insomuch that the
sales table would've had the names and addresses & phone numbers of each
sales client, when it had been designed to have a separate table for these
clients with only the id field of the client linked in the sales table. I
consulted on the newsgroup--should I "dumb down" my design so it could
import the data, or keep it & explain to the client that he needed the
supplier of the data to supply it in a slightly different format to be more
compatible with my database. Every last poster here voted the latter, and
that's what I did. I did so kindly, but it's what I did.

I lost the client. But I figured--I shouldn't dumb down my database,
especially since doing so would remove many of the features he had actually
been the one to ask for. I did later on, as my expertise improved, learn how
I could've actually done this for him. But at the time I couldn't. Live &
learn.

LRH


"Tim Marshall" <TIMMY!@PurplePandaChasers.Moertherium> wrote in message
news:d7lh31$dck$1@coranto.ucs.mun.ca...[color=blue]
> Larry R Harrison Jr wrote:
>[color=green]
>> I hate strays from the norm which complicate things,[/color]
>
> And that's what you will always have to contend with as a DB developer.
>
> 8)
>
> Be prepared for furrowed foreheads of clients who are upset when they
> discover a miniscule fraction of data is not dealt with. Those clients
> will view such an app as garbage and will be unable to appreciate the work
> and elegance you may have driven yourself into the ground to provide...
> just because of that small fraction. Been there, done that. 8(
> --
> Tim http://www.ucs.mun.ca/~tmarshal/
> ^o<
> /#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
> /^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me[/color]

re: Hyphenated Name Field

Larry R Harrison Jr wrote:[color=blue]
> <jimfortune@compumarc.com> wrote in message
> news:1117652710.438237.260330@f14g2000cwb.googlegr oups.com...
>[color=green]
> > So is the thinking that the client would be bending things by asking
> > that this situation be handled.
> >
> > James A. Fortune
> >[/color]
> In some cases, absolutely. For example, I have actually had persons before
> wonder how come their attempts to enter data crashed when they tried to
> enter the state in the Zip code. They enter some names as "O'Brien" and
> others as "OBrien" and still others as "O Brien"--only to then wonder why
> not all of those are sorted together as if they're the same. They wonder how
> come a query they later add themselves for showing "O'Brien" returns
> inaccurate numbers because of the other variations entered.
>
> ...
>
> In closing--I typically post here with extremely practical questions, not
> opiniated ones. I typically ask questions like "what syntax is appropriate
> for creating a joint query in SQL." I will make sure to stick to such
> questions in the future for the most part and hopefully not waste anyone's
> time here; I realize Microsoft MVPs and the like are hanging out here to
> help & don't want to get sucked into long-winded opinion discussions. I am
> asking as a designer, not trying to be opiniated politically so much as that
> the objective here is the protection of data integrity, not sucking up to
> people's whimsical fascination with titles & so forth.
>
> LRH[/color]

Opinions aside, if O'Brien, OBrien and O Brien are truly equivalent as
demonstrated by a table containing numerous misspellings then you can
run a query on that table to create tblAlternates as a way of merging
the variants.

tblPeople
PersonID PK
LastName Text
....

55 O'Brien

tblAlternates
AltID PK
VariantID FK
Preferred Y/N
NameVariant Text

21 8 -1 O'Brien
22 8 0 OBrien
23 8 0 O Brien

Obviously Preferred will be -1 for the preferred variation. You also
need to take requisite care that two different last names don't have
variants that are spelled the same.

Then in the AfterUpdate event of cbxLastName you can use SQL such as:

"SELECT NameVariant FROM tblAlternates WHERE VariantID IN (SELECT
VariantID FROM tblAlternates WHERE NameVariant = " & Chr(34) &
cbxLastName.Value & Chr(34) & ") AND Preferred = -1;"

If this SQL string returns a value you can replace the value entered in
cbxLastName with the the preferred version of the last name. At least
this way you only have to deal with variants that are new.

Opinions on. If people want whimsical titles then our sense of
protection of data integrity should protect those fanciful titles also.
Let someone else burst their bubble. Put the money in your wallet.

James A. Fortune

I will be following this closely:
Earlier this week, Microsoft Chairman Bill Gates said Longhorn, due in
2006, will have a new XML-based document format, code-named "Metro,"
that will be used to both print and share documents.
-- C|Net April 27, 2005

re: Hyphenated Name Field

If you don't hate women, perhaps you should not assume that those with
hyphenated names are "feminazis" (as you called them in another post).
Since this is a derogatory term, your use of it distinguishes you as a
mysogynist.

Major error: hyphenated names were not invented by feminists or
feminism. They are very common. Actress Julia Louis-Dreyfus, for
example, has a hypenated name with which she was born. She didn't pick
a hyphenated name. It IS her name. She didn't pick it to make a
feminist statement or to annoy some lowly coder.

Further, plenty of men (such as Julia Louis-Dreyfus' brother and father)
have hyphenated names. Also, many commercial firms use similar
nomenclature (such as in the Smith-Barney example).

It is simply childish to characterize common customs as some sort of
personal affront to you. Further, I think your attitude as a developer
absolutely stinks. Your job is to help the client acheive their goals,
not to scold them for not conforming to your narrow view of the world as
you think it should be. As a developer, I think I have to find a way to
make the data work from the form to the data entry to the queries and to
the reports. That's MY problem and it's my job to solve it.
Accomodations to exceptions are a small price to pay when compared to a
disappointed client.

Were I your client or your supervisor, I'd fire you for your "can't-do"
attitude. Your mysogyny and borderline racism - yes, hyphenated names
are common to people with certain types of national origin - are
unacceptable and expose your employer and your client to liability. You
would be SO fired.

You say all this nonsense while you claim to be willing to accomodate a
client. I guess you are willing to accomodate only those client needs
that conform with your view of the world rather than the reality of the
client's data. That's the OPPOSITE of accomodation.

Your denial that you are hateful or sexist rings completely hollow.
Take your lousy attitude elsewhere and keep your dittohead politics out
of this forum.

*** Sent via Developersdex http://www.developersdex.com ***

re: Hyphenated Name Field

If you are not trying to upset anyone, stop trying to upset people with
the name-calling. Completely unprofessional. Makes you look like a
real jerk.


*** Sent via Developersdex http://www.developersdex.com ***