Ain

You wrote, that you think about optimizing amount of data sent over the
wire and you will have lots of records travelling back and forth, so
lets say that we use integer for flags and we have two sets of
select/update statements:

1. Long object names:

SELECT FIRST_INTEGER_FLAG, SECOND_INTEGER_FLAG, THIRD_INTEGER_FLAG
FROM THE_VERYLONG_NAME_TABLE
WHERE SOME_FIELDNAME = 1

UPDATE THE_VERYLONG_NAME_TABLE
SET FIRST_INTEGER_FLAG = 1, SECOND_INTEGER_FLAG = 2, THIRD_INTEGER_FLAG = 2
WHERE SOME_FIELDNAME = 1

2. Short names
SELECT F1, F2, F3
FROM ATABLE
WHERE S_F = 1

UPDATE ATABLE
SET F1 = 1, F2 = 2, F3 = 3
WHERE S_F = 1

And then imagine amount of data sent to server in both cases. I don't
know client architecture but sql statements are interpreted by a server
and probably client library transfers them unchanged. So optimizing the
amount of data received consider also amount of data sent to server. So
to achive fast data exchange between your app and your db server you
have to also 'optimize' amount of bytes sent not only received.
I hope you got the poin here...

Marcin




ainpoissee pisze:

> --- In firebird-support@yahoogroups.com, Marcin Bury <mbury@...> wrote:
>> It won't make a difference when you have "longer" db object names - it
>> makes sense when you keep them as short as possible. Two, three
>> characters more in names and your "optimization" for flag fields is
>> gone... ;-)
>
> Oh, thats another thing I have been wondering... does the object name length matter (when keeping query speed in mind)?
> I do have a habit to use prefixes for object names, ie table name starts with TAB_, view's with VIEW_ etc... I tougth that index compression sheme would optimize away the common prefix so it wouldn't make any noticeable difference, but is this is really the case? Or would it be better to drop the prefix (or use common suffix if I really want to have hint of the object type in it's name)?
>
>
> TIA
> ain
>
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>