Hi Geoff,
Many times the need for longer metadata names is to compensate for the lack
of other functionality.
For example, due to the extreme functionality of Firebird/Interbase, long
before modern database tools where common, I would preface any object with
an indicator as to what it is, such as table/procedure so that my trigger
and procedure code was far more readable and easier to debug.
I then would preface the same things with code to indicate what part of the
project, that item is used in (costing, billing, call processing etc) in
order to know what that item was to be used for at a glance.
Then, some code was used by specific developers........
This is all before packages and other things, but, you can soon see that
the longer names where used as a work around for existing limitations.
The other issue has to do with french/english legibility due to
bilingualism of the end users.
With schema/synonyms/recursive structures, you not only allow for code
bases to be more catering to the end user, you also make it easier to
maintain the code and reduce the need for extremely long names.
I can see supporting names up to the maximum supported by ODBC as that
eases code/application porting as well and making it easier for developers
transitioning to Firebird.
But, I see the support for a recursive structure for schema as removing
most of the need of longer names.
If the change takes place in the parser, where the parser looks up the
SQLObject name from a recursive table structure, then uses the internal
iterative name for processing/blr, would give the most flexibility while
keeping the code changes as small as possible.
Plus, once we support schema and synonyms, we can then look at possibly
having a master system with child databases attached, acting as a single
large system. Oracle already supports this.
It is not for beginners, but, for those who know what they are doing, it
makes life so much simpler.
best regards
Dalton
On 13 June 2016 at 08:56, Geoff Worboys <ge...@telesiscomputing.com.au>
wrote:
> Dmitry Yemanov wrote:
> > 03.06.2016 16:11, Adriano dos Santos Fernandes пишет:
> >>
> >> The major thing to discuss here is, what should be that
> >> character limit: 64, 128, other?
>
> > I'm afraid the new limit should be 63 characters. 64 UTF-8
> > characters means 256 bytes which does not fit BLR (string
> > length counter is single-byte there, max possible length is
> > 255 bytes).
>
> > Or we need to switch to longer BLR strings together with
> > longer context numbers, using a new BLR version.
>
> Do we have any real-life examples of why people want longer
> names? Something to target?
>
> There have been a few times where I would have liked a few
> extra characters for a procedure name (mostly because I tend
> to use name prefixes for various reasons, leaving less room
> for an actual name part). But it's rarely been much of a
> problem. So, in my case as one example, 63 would be
> absolutely fine.
>
>
> If this change is going to be lots of work then I'd rather see
> the effort put into a more comprehensive solution like the
> option 3 suggested by Dalton Calford. Most of the projects I
> have been involved with have tried to solve the localisation
> of object names in one way or another (even if, in many cases,
> the "localisation" has been only to localise programmer-speak
> into English ;-). Internalising that capability would be a
> nice thing to see and could offer other benefits as well, like
> being able to rename any object at any time without impact to
> the structure.
>
> --
> Geoff Worboys
> Telesis Computing Pty Ltd
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
