Hi Helen,

Helen Borrie wrote:

> That's true, though it's not really a limitation of significance technically. It's more in the nature of being a practical limitation to those migrating databases from more "tolerant" systems - usually just one of a number of compatibility issues that have to be considered for a migration.
>

And as few "compatibility issues" FB have, more easy would be to others
adopt it ;-)

> To construe it as a reflection of the "poor state of the original code" is misleading. Firebird inherited a system that started its life on hardware and OS's with extreme resource constraints by comparison with today's platforms. The 31-byte limit on identifiers was a totally justifiable in 1984...so if it's a reflection of anything, it is of the stable design precepts of the original code.
>

Well, I could argue that a "good state of the original code" would give
an option to change a constant that define the identifier size and
that's all what need to be done :-)

> Ease of migration from wacky desktop systems and wacky non-desktop
> systems is a desirable objective. Being able to name a field
> "Grandmother's Favourite Recipe for Christmas Cake" has some appeal
> for spreadsheet enthusiasts; it's debatable whether it's particularly
> high in the priorities for improving the stability and performance of
> databases...
>

I don't think big names are a matter of bad design or amateur code,
neither that long names are a matter of good design, but I can tell you
that 31 bytes is a bit short to make descriptive names in a bunch of
situations (composite names in this case), I deal with it, but if I
could avoid abbreviate I prefer, I am against crypt names that are hard
to remember.

I prefer to type
Quantidade_Vendida_Total_Almoxarifado (Warehouse_Total_Quantity_Ordered)

than to remember if I used
Qtd_Vendida_Total_Almox or Quant_Vendida_Total_Almox

In my life I had encountered more than once systems where the Tables are
named like Tab001, Tab002, Tab003 and the columns Tab001_001, Tab001_002
and the like, for this kind of system 31 chars are more than enough :-)

But the length limitation is more critical at other places than the
column names (constraint names is where I face most of the problems).

I have 2 tables Titulo_Receber and Titulo_Receber_Baixa, I'd like my FK
be named FK_Titulo_Receber_Titulo_Receber_Baixa, I need to change it to
something FK_Tit_Rec_Tit_Rec_Baixa I am giving this example from the top
of my head, but I am sure there are others where the name are not so
obvious and easy to remember.

> ./heLen
>

I am not trowing stones, I like FB very much, and I appreciate even more
all the work done by the fellow developers, but there are places that
need improvements, and everyone using it must wait for it or provide
ways to make it faster (sponsoring a feature or devoting time), I am in
the group that must wait :-)

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br