[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: future coding standards for stored procedure names
- Subject: Re: future coding standards for stored procedure names
- From: herman vierendeels <..hidden..>
- Date: Fri, 25 Nov 2011 18:26:13 +0100
This is a bit new to me.
Could you tell a little more about the function of a separator in a
Is this separator meant to be interpreted in pre-db code or in the db itself?
Object oriented guys would prefer object->method syntax.
2011/11/25 Chris Travers <..hidden..>:
> I am thinking one area we probably want to firm up our coding
> standards is in the area of stored procedure names. There are two
> fundamental issues I see with our current approach in 1.3. The first
> is that the double underscore approach really doesn't work well except
> in the case of roles where it is enforced by the application. The
> second is that verbs end up going wherever they seem like they should,
> and this makes the API somewhat hard to learn.
> I would suggest instead think about this and try to standardize as
> much as possible going forward, at least into 1.4.
> Basically I think we should standardize on one of the following two formats:
> This leads to two questions:
> 1) Which of these is preferred? I am leaning towards the second
> because it suggests a sort of Subject-Verb-Object syntax relatively
> familiar to us Indo-European speakers (languages which include
> English, Spanish, etc). In cases where the second noun doesn't apply,
> it's pretty clear also. So for example company_pkg_get (with pkg as
> the $sep) is clear, as is company_pkg_get_credit_accts. Here we know
> we have a company and we are getting related credit accounts.
> 2) What kidns of separators should we use? One option might be to
> look at non-alphanumeric characters that could be differentiated by by
> sight, something like:
> The big issue here is that omitting the double quotes renders this
> unusable and this makes manual use a little more bothersome, and this
> could lead to dangerous errors if new operators are ever added which
> conflict with the choices made. However if we go with this route, we
> can remove the underscores around sep, leading to something like
> "company:::get" or "company->get"
> The second possibility is to use an alphanumeric string to
> separate.the components. Say, pkg in the above example.
> I am personally leaning towards the "company->get" syntax (and
> "company->get_credit_accounts"). I think it is the easiest to read,
> and most frameworks are likely to automatically quote the identifier
> What does everyone else think?
> Best Wishes,
> Chris Travers
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> Ledger-smb-devel mailing list