Philipp Post wrote:
> you will not find examples on naming boolean columns in "SQL
> programming style" as page 42 mentiones, this data type should be
> avoided. Indeed in most cases there are better ways to model the data
> than with BIT columns. In cases where you can not avoid it (or choose
> not to do),
If you mean avoiding non-standard extensions, my so-called "booleans"
are actually defined with INTEGER foo NOT NULL CHECK (foo BETWEEN 0 AND
1), and always will be as long as I have breath.
> 2004], [Watt 2004] to ensure that the meaning of the data is not
> ambiguous. See these links:
> http://weblogs.asp.net/jamauss/articles/DatabaseNamingConventions.aspx
> http://justinsomnia.org/writings/naming_conventions.htm
Thank you very much.
I've never been imposed styles or best practices, so in forming my own
blend, the more references I have, the better.
> Personally I like the pascal case naming convention there what solves
> the problem of acronyms and abbreviations and says that all
> abbreviations with two letters are to be uppercased, such as ID or DB
> and with three or more letters follow the pascal case convention, i.
> e. first upper, following lower cased e.g. EanCode.
Oh, no, this is not my piece of case.
(ahah. pun.)
|
