Lucian

>How come a longer name (obviously very explicit and clear) can become a
>readability issue, I can't understand...

How long did it take you to spot the difference in Itzok's post?

ABCCUSTOMERXXX-9B27A24391274FD5BFAEB5438777523B
ABCCUSTOMERXXX-9B27A24391274FD58FAEB5438777523B


Roy Lambert

The example was bad. Keyword are "company name"-"application name".
It would actually be more like this and you'll spot it instantly:

LEGAL_ABC-DOCPERFECT-9B27A24391274FD5BFAEB5438777523B
LEGAL_ABC-POWERS-32563456A24391274FD58FAEB5438777523B
LEGAL_ABC-WILLS-9B27A24391274FD58FAEB5438777523B
LEX_SUPER-DOCPERFECT-3258024509234509287565435568345
LEX_SUPER-WILLS-35689373249O6931285709234857986
DURA_MATTER-WILLS-3450912850260928347509812365092348

regards,
Lucian

Without Company name, app name, you go and spot which one is "LEX
SUPER" having "DOCPERFECT", and imagine 2000 customers. Let me know how
long it will take you to find it:

9B27A24391274FD5BFAEB5438777523B
32563456A24391274FD58FAEB5438777523B
9B27A24391274FD58FAEB5438777523B
3258024509234509287565435568345
35689373249O6931285709234857986
3450912850260928347509812365092348


(disregard what doesn't look like a GUID - I just typed random crap)
Lucian

Roy, you realize that the issue now is "readability". Yeah, I could
probably take out the GUID from the db name, however, if I also take
out 10 chars for the application code which I need (it can not be
reduced more, because it happens this code is very old and won't change
easy - like Tim's issue) - I still have to truncate long company names
that won't fit. That's the thing. Hopefully there may not be 2
companies with similar long names which if truncated would result in
the same string.

The issue with database name length remains, why would I have to do
these kind of tricks in my app? If John Doe looks at the database names
and sees the funny truncations (man, it could truncate some names very
funny) it'll think the developer was retarded and couldn't have few
bytes more there... kind of Y2K bug


Lucian

BTW, when I started this thing, I thought "GUID is cool" and had no
idea what the database name length is ... shoot myself in the foot
thing.

I think I abandoned the GUID few hours after my initial post I
said I'm dropping this one

--
Lucian

Lucian

>Roy, you realize that the issue now is "readability".

Even with the examples you posted I had major problems. I think its probably something to do with reading from left to right, by the time my eyeballs had finished tracking the data was so similar that my mind didn't process the intermediate leading characters. I saw LEGAL_ABC followed by a load of gibberish and assumed it was the same. Its how people can recognise badly misspelled words or broken words which computers don't recognise - look at viagra ads.

>Yeah, I could
>probably take out the GUID from the db name, however, if I also take
>out 10 chars for the application code which I need (it can not be
>reduced more, because it happens this code is very old and won't change
>easy - like Tim's issue) - I still have to truncate long company names
>that won't fit. That's the thing. Hopefully there may not be 2
>companies with similar long names which if truncated would result in
>the same string.

Old code is a bit like old programmers. Always a problem

>The issue with database name length remains, why would I have to do
>these kind of tricks in my app? If John Doe looks at the database names
>and sees the funny truncations (man, it could truncate some names very
>funny) it'll think the developer was retarded and couldn't have few
>bytes more there... kind of Y2K bug

I've never regarded the Y2K bug as a bug. It was a very sensible decision at the time it was made. The problem was old COBOL code just kept on running. It'll be interesting to see how many modern applications last as long.

In theory Tim could have made the names 1024 chars long (the max length of a VARCHAR/CHAR) but that would have been really silly. A decision had to be made and most of the time, for most people 40 chars is going to be fine. Sometimes it isn't and where its old code that you can't really do anything about there's a problem.

Roy Lambert

> Even with the examples you posted I had major problems.

Well, yeah ... but we shouldn't be talking about readablity when stuff
contains GUID in it. If there weren't any GUIDs there I suppose you
would have seen the differences pretty easy.

Yes 40 chars is more than enough in most cases, I agree. I was talking
from my own perspective of what a customer-developer relation is: like
I said, for me (or my boss for this specific matter: field lengths) ...
the customer is always right. I have tons of field lengths mods done
during the past 20 years in the code I maintain.

***

To increase the db name length ... I don't know what that involves, I
understand it's difficult.  Ok, fine


regards,
Lucian

Lucian,

may I ask a simple question: why don't you use just a GUID for your
databasenames and create an "Admin"-Table that contains all your
customers and the corresponding databases?
It should be easy to query these tables using a join - and you are done.

Regards Uli

Lucian


Yup - its the old answer to "how do I get to" being "well I wouldn't start from here"

Roy Lambert

Hi Uli,

My boss suggested an approach that will allow easy access outside the
application (via edb manager was my idea) and that's why I thought,
wow, is going to be me (at least for a while) to be looking at this
stuff so, let's make it friendly. Bottom line is I believe an admin
application alltogether will be required and we'll add stuff to it on
the fly. Probably will have stuff like what you suggest in it.

regards,
Lucian