September 28, 2017 at 1:37 am
Depending on the product used for the presentation layer, you may find the column names will be prettified automatically. We use DevExpress and it separates the words in a CamelCase column name by default; other products may do this too and some may do it for underscores instead/as well.
September 28, 2017 at 5:06 am
Personally, I prefer CamelCase. I know that some prefer Underscores though, and I don't specifically have anything against that. Like everyone else has said, names with spaces it are not nice. I hate having to wrap object names in square brackets, which also means avoiding using column names that are reserved words (don't call a column Group for example), starting the name with a numeric, etc.
The company I'm at at the moment likes to put suffixes on the names of objects. For Tables _tbl, for Store procedures _sp, views _viw, etc, etc. This seems to be more for the Web Dev's than anything, as when I've they've complained and asked a question like "What is 'AddNewItem'? Is it a table, a view?".
Presentation layers are the "best" place for friendly names, and some are quite clever at doing this automatically. For example, SSRS would change OrderNumber or Order_Number to "Order Number" when you add the column. This makes things just that little bit quicker.
Consistency is definitely important as well; both for formatting and names. Calling a column "Code" in one table and "Agent" in another isn't helpful to anyone (talking from experience).
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
September 28, 2017 at 6:56 am
I actually like spaces in conjunction with square bracket quoting (of course, to be used consistently for specifical lexical reasons).
On a second note, I see people using camel case a bit incorrectly. To be a bit pedantic:
thisIsAVariable <-- camel case
ThisIsAVariable <-- Pascal case
I like Pascal case too for things like parameter names and the like but being a bit old-school I tend to use all caps and underscores for constants (or the pseudo constant variables forced by T/SQL's lack of actual constants).
September 28, 2017 at 1:20 pm
Let me go ahead and post a quick summary of things:
first basic principle: a data element name should be as universal as possible. In English, "Job" is the name of an Old Testament prophet, while "job" is a possible name the category of activities. Starting see the difference?
1) many ISO standards are case insensitive, and many are not. Therefore, it is important to establish a naming convention. It's also important to never, never use Pascal or camel case! Space is not one of the things you should ever, ever use.
2) The Unicode people defined a subset of characters, which are basically the lower end of the old ASCII code set (letters, digits, and simple punctuation), that are common to all languages on earth. This is so that somebody in some god-awful absurd character set can still get the basic metric abbreviations, international encodings, etc. in a standard format.
The metadata and ISO 11179 committee defined rules for naming data elements. Here is a summary, you should use
[<Collective_data element>][role_]<data element>_<data property >
This means "Forest.tree.diameter" is valid , but "Trees.tree" is not, etc
Again, get one of my books or Google it.
Please post DDL and follow ANSI/ISO standards when asking for help.
September 28, 2017 at 1:54 pm
Did anyone else hear a horse come through?
September 29, 2017 at 3:25 pm
Lynn Pettis - Thursday, September 28, 2017 1:54 PMDid anyone else hear a horse come through?
I thought it was a donkey, not a horse.
Tom
September 29, 2017 at 3:34 pm
jcelko212 32090 - Thursday, September 28, 2017 1:20 PM2) The Unicode people defined a subset of characters, which are basically the lower end of the old ASCII code set (letters, digits, and simple punctuation), that are common to all languages on earth. This is so that somebody in some god-awful absurd character set can still get the basic metric abbreviations, international encodings, etc. in a standard format.
Interesting claim! I hope that most people who see it will dismiss the statement that the letters at the bottom of the old ASCII code are common to all languages on earth as the absolutely contrafactual drivel that it is.
Last time I looked at Russian didn't use the letters at the bottom end of the old ASCII code letters, nor did Japanes, nor did Chinese, nor did any of the various forms of Arabic, nor did Tamil, nor did Urdu, not did Hindu, nor did Gujurati, nor did Telugu, nor did hordes of other languages. Most of the languages I have come across don't use those characters. The basic metric abbreviation for what is in English a kilogram shows up as કિલો in Gujurati and கிலோ in Tamil and किलो in Hindi.
Indeed it is a plain and simple fact that the majority of the languages in the world do not use those characters. So clearly these characters are not common even to most of the world's languages, never mind to all of them.
Tom
September 29, 2017 at 4:44 pm
TomThomson - Friday, September 29, 2017 3:34 PMjcelko212 32090 - Thursday, September 28, 2017 1:20 PM2) The Unicode people defined a subset of characters, which are basically the lower end of the old ASCII code set (letters, digits, and simple punctuation), that are common to all languages on earth. This is so that somebody in some god-awful absurd character set can still get the basic metric abbreviations, international encodings, etc. in a standard format.
Interesting claim! I hope that most people who see it will dismiss the statement that the letters at the bottom of the old ASCII code are common to all languages on earth as the absolutely contrafactual drivel that it is.
Last time I looked at Russian didn't use the letters at the bottom end of the old ASCII code letters, nor did Japanes, nor did Chinese, nor did any of the various forms of Arabic, nor did Tamil, nor did Urdu, not did Hindu, nor did Gujurati, nor did Telugu, nor did hordes of other languages. Most of the languages I have come across don't use those characters. The basic metric abbreviation for what is in English a kilogram shows up as કિલો in Gujurati and கிலோ in Tamil and किलो in Hindi.
Indeed it is a plain and simple fact that the majority of the languages in the world do not use those characters. So clearly these characters are not common even to most of the world's languages, never mind to all of them.
No Tom, the abbreviation codes for the metric system (SI) are all defined with the Latin alphabet and a set of punctuations. The Unicode people require every language set to have them available. And so are all of the ISO standards that I know anything about. Embedded spaces are not allowed, because they would cause white space problems in transmission. Only a limited set of punctuation marks are allowed.
This is why if you have to design your own encoding schemes, this is the character set which you should pick. Have you actually used Gujarati characters when you have had to design encoding schemes? How about Roman numerals? Or do you prefer traditional Chinese numerals?
Please post DDL and follow ANSI/ISO standards when asking for help.
September 29, 2017 at 7:47 pm
No Joe, you are missing the point. The SI abbreviation codes are not part of, for example, the Russian language in the sense that they are used normally by Russian people, they are non-Russian chunks that are used when needed to help communicate with non-Russians. Neither ISO nor the Unicode people can dictate to the Russians what is and what is not part of the Russian language.
For example the Russian abbreviation for КилограÌмм is кг not kg, and you can see that plainly stated "КилограÌмм (руÑÑкое обозначение: кг; международное: kg)" which means "Kilogram(Russian symbol: кг; international: kg)" at the head of the Russian wikipedia article on the kilogram.
Similarly, the Russian wikipedia article on the nanometer says "ÐаномеÌÑ‚Ñ€ (руÑÑкое обозначение: нм; международное: nm)" , that is "Nanometer (Russian symbol: нм; international: nm)".
To answer your question about what encoding I have used, I'll say that I wouldn't dream of devising my own coding scheme for text in a human language because the unicode people have provided me with a coding scheme that meets all my requirements for encoding written languages (encoding for other stuff is of course irrelevant to this conversation about languages). What I have done in the past is use professional translators to translate text from one language into another (and have it validated by some other person who speaks both languages and whose native language is the source language and also by someone who speaks both languages and whose native language is the target language, and then code it using unicode. This led to satisfied customers who could provide descriptions of their services on a website that allows their clients to search for features and purchase services and goods and information about local facilities using up to 5 languages (chosen from a larger set) per system. Numerals are of course different in different languages: the number one million in Western Arabic numerals might be writen 1,000,000 or 10,00,000 or 1.000.000 depending on the language; There are 20 or more variants of Hindu-Arabic numerals other than the Western Arabic used pretty well throughout the Europe and the Americas; which set of glyphs to use is a matter for the translator, as is the punctuation of the numbers; but I don't think that for my customers any numeric characters other than one of the 21 or more Hindu-Arabic glyph sets used for base 10 notation would have been relevant.
Tom
September 30, 2017 at 3:24 pm
When my books were translated, I was told to not spell out ISO measurements in either English or Russian, but to use the ISO abbreviations. I had the same basic style guides in Japanese and Chinese books and articles for the same reasons from those publishers. The goal was to make it as portable and international as possible for techies.
I've had problems going from British English to American English, when was writing a regular column for a trade paper in the UK years ago. The style convention is that American spelling trumps British in technical terminology ("program" if it's on a computer and not "programme", try to remember to put in the next are "u" in "honor", "color" and so forth, always use the ISO abbreviations for measurements, etc.
The only real problem I ever had was having "SQL for Smarties" translated into French. The translator never talk to me, never sent me a style guide or anything. I saw the final product when it was in print. And in a very typical French approach to language, even the variable names had been forced into French. We had a rule in ANSI that if anything was being held up on anything to do with language or character sets, it was the French. Not the Chinese. Not the Japanese. They were too polite 🙂
Please post DDL and follow ANSI/ISO standards when asking for help.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply