Question about design practice - Address table

In a db, is it a good practice to have Address info in Address table in uppe
r
case or lower case?
ex: street name, city, state, county, country etc..
How about name [first name, middle name, last name, prefix, suffix...]
If you have any links that talk in detail about this, I'd like to read them
too
[ Some background: I am looking for some strong points so I could make an
impact in decision making...about best practice]
thanks everyone,
_UdayUsing all lower case for data is terrible. All upper case is bad -
takes me back to my mainframe days when we hardly knew there was a
shift key. I strongly prefer data read by people to be in proper
case: John Smith, Main St, Springfield.
State abbreviations are two character upper case: MA, OH, NY, CT, NJ,
WA.
However, when addresses are printed for the US Postal Service, they
prefer all caps. That change can be made during the printing process,
if at all.
Roy Harvey
Beacon Falls, CT
On Tue, 2 May 2006 12:11:02 -0700, Uday
<Uday@.discussions.microsoft.com> wrote:

>In a db, is it a good practice to have Address info in Address table in upp
er
>case or lower case?
>ex: street name, city, state, county, country etc..
>How about name [first name, middle name, last name, prefix, suffix...]
>If you have any links that talk in detail about this, I'd like to read them
>too
>[ Some background: I am looking for some strong points so I could make an
>impact in decision making...about best practice]
>thanks everyone,
>_Uday|||Default server collation is case in-sensitive.
So first step is, if you are worried about the case. check the collation of
the server,database. and upper case or lower case is a display property and
should be handled in the front end and usually based on requirements.
Hope this helps.|||I agree with you Ron. But the people who make decisions don't see data the
way I see it. So I need some strong points to make an impact on the decision
.
If I just say, 'keep the data in its original format' -- I dont think that'l
l
make a strong point. Hope you can understand the position I am in.
thanks to you all...Ron and Omnibuzz
_Uday
"Roy Harvey" wrote:

> Using all lower case for data is terrible. All upper case is bad -
> takes me back to my mainframe days when we hardly knew there was a
> shift key. I strongly prefer data read by people to be in proper
> case: John Smith, Main St, Springfield.
> State abbreviations are two character upper case: MA, OH, NY, CT, NJ,
> WA.
> However, when addresses are printed for the US Postal Service, they
> prefer all caps. That change can be made during the printing process,
> if at all.
> Roy Harvey
> Beacon Falls, CT
> On Tue, 2 May 2006 12:11:02 -0700, Uday
> <Uday@.discussions.microsoft.com> wrote:
>
>|||Uday.
Few points to remember.
1. If you define some rules saying the names should have the first letter
caps, how are you going to enforce it. Can you prevent a user from inserting
a value that doesn't comply to the standards. You can , by doing a check
constraint with a series of string functions (which SQL Server is not exactl
y
built for). But does it really have any sense to do the check.
Think of SQL Server as a datastore. If the format of storage changes at a
later date (say all caps for the names). How will you enforce the new
standards. Its always better to handle the formatting part in the front end.
That would be my standpoint.
Hope this helps.
--
"Uday" wrote:
> I agree with you Ron. But the people who make decisions don't see data the
> way I see it. So I need some strong points to make an impact on the decisi
on.
> If I just say, 'keep the data in its original format' -- I dont think that
'll
> make a strong point. Hope you can understand the position I am in.
> thanks to you all...Ron and Omnibuzz
> _Uday
> "Roy Harvey" wrote:
>|||it would seem to me that you can only start "doing anything" with the
case in SQL server if you change the collation of the database. I
expect that if used well then this wouldn't be a problem, but I've had
numerous headaches from having to move databases between servers, then
finding the collation is different to the master (which means any SPs
with WHERE colA = 'some value' throw collation conflict errors).
I'd keep with the default collation, it makes everything simpler. As
others have stated, use your front end to do all the validation etc.
then you won't need to wrestle with DTS etc. just to change collation.
Incidentally, I haven't looked into it, but does anyone know if they've
made it easier with 2005 to change a database collation?
Cheers
Will|||You should always store data with as much information contained in it as
possible. You can always convert to all lower or upper or any combination
coming out.
It's like using your digital camera, and saving in a robust (granted, large
file size) on the memory card. You can always shrink it later when you want
to email the pic
Jeff
"Uday" <Uday@.discussions.microsoft.com> wrote in message
news:1162A9EF-6E79-431D-9FF4-FB6FC1AD39F3@.microsoft.com...
>I agree with you Ron. But the people who make decisions don't see data the
> way I see it. So I need some strong points to make an impact on the
> decision.
> If I just say, 'keep the data in its original format' -- I dont think
> that'll
> make a strong point. Hope you can understand the position I am in.
> thanks to you all...Ron and Omnibuzz
> _Uday
> "Roy Harvey" wrote:
>|||Omnibuzz (Omnibuzz@.discussions.microsoft.com) writes:
> 1. If you define some rules saying the names should have the first
> letter caps, how are you going to enforce it. Can you prevent a user
> from inserting a value that doesn't comply to the standards. You can ,
> by doing a check constraint with a series of string functions (which SQL
> Server is not exactly built for). But does it really have any sense to
> do the check.
Yeah, think about Ludwig van Beethoven for example.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Thanks Omnibuzz..!! It sure helps.
I'll try the case-insensitive coallation... and let the data be in which
ever format it is entered. I'll change it on the fly in front-end or as
needed.
Thanks everyone,
_Uday