|
Use of nicknames vary greatly from one culture / country to another. Here in Norway 99% of the population are called by their 'real' names - to the degree that Bill Bryson (yes, yet another Bryson quote!) tells in "Neither here nor there":
"I had had huge difficulty persuading the staff at the Kredittkassen Bank on Karl Johans Gate to cash sufficient traveller's checques to pay the extortionate 1,200 kroner bus fare - they simply could not made to grasp that the William McGuire Bryson on my passport and the Bill Bryson on my traveller's cheques were both me"
I've seen it from the other side as well: Don't expect every Norwegian to have a middle name. Today, it is seen more often, but in my generation, I hardly know of anyone with a middle name. I wanted some information from a USA web site that required me to create a user, asking for my real name, and they insisted on a "middle initial". American forms for specifying names almost invariably has a field for the middle initial, but you may leave it open. Not on this website, it insisted on an alphabetic character, A-Z. Space, hyphen or other punctuation marks were not accepted, you had to reveal your middle initial. Of course you have one - everybody have a middle initial! Sure, I don't think I've ever met anyone from the USA without a middle initial.
We do use double first names: My best buddy in childhood was named Per Erik, one of my current friends is named Per-Kristian, my father was named Torleif (Tor Leif, but as one, unhyphenated word). The double name is always used in full: If you asked me when I was ten if I knew of any 'Per', Per Erik would never occur to me. Per-Kristian is not some 'Per' that I know today. If you suggest that my father was named Tor, I would protest; that is simply wrong.
In my parents' generation, it was more common to have a double, unhyphenated first name, but use only one of them in everyday life. I knew my mother's other first name, but didn't know until several years after moving out from my parents' that my father had a another first name! They would never indicate the initial letter of the other first name as a "middle initial" - the other name is still a first name, not a middle name! The same goes for lots of other people of that generation that I know.
I guess that one reason why we rarely use nicknames is that the major part of Norwegian first names are short, 1 or 2 syllables. All the 4-syllable names I can think of are really two concatenated names. Most, but not all, 3-syllable names are also concatenations of two names, a single-syllable one and a 2-syllable one. So we don't have any need for shortening down the names!
|
|
|
|
|
Mandatory middle name?
An ex-coworker had a girlfriend from Indonesia, and where she's from they simply don't have a last name...
Apparently, it's legal in the Netherlands to not have a last name as long as you don't have the Dutch nationality.
As soon as you get Dutch nationality you need to pick a last name.
Anyway, she didn't have a last name officially, but for most forms she had to use her made up last name (which was official-ish, I guess).
What's more, they got a child, and a first child can have the last name of the mother or the father.
Most pick father, but they picked mother, so the child doesn't have a last name either.
I believe (s)he(?) gets to pick both his nationality and last name when (s)he turns 18.
|
|
|
|
|
My previous employer had a number of employers from India. They were complaining when we were redesigning our business cards from landscape format to portrait: Their official name was so long that it didn't fit in. In one case, even if you put the first and last name on separate lines, both were too long to fit. Not very surprising: Every one of those people had a nickname, usually of two syllables, three at most.
Another thing to be aware of: If you ask one of those guys whether his long name has any particular meaning, be prepared to spend the night to hear the explanation! At least to some of them, the true meaning of their name is quite significant - far more than for any European or European American that I have ever discussed the matter with. Quite a few have no clue about the origins of their name, except possibly those who can refer to this or that biblical person. (And it stops there - they don't know the meaning or origin of the biblical name, and hardly know any treats of that person that they associate themselves with.)
|
|
|
|
|
You use column names in your code?
|
|
|
|
|
Having worked on a system that used some of Jeremy's mapping alternatives I recommend that you NEVER do this, attempting to track through from a field name on a form/class that is different to the column name in the database is a nightmare.
You would be just adding complexity for the sake of it, adding multiples to the support cost and the supporting dev will have a wax effigy of you and be sticking needles in it!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: Having worked on a system that used some of Jeremy's mapping alternatives I recommend that you NEVER do this I'm trying to collect $20 though...
Jeremy Falcon
|
|
|
|
|
I have frequently seen that kind of arguments, and very similar ones, used to justify that end user with a vague idea about the meaning of English terms nevertheless have to accept them, because those are their real names, and using anything else would be confusing and misleading.
It would be fascinating if Chinese hardware and software developer switched to a similar approach.
|
|
|
|
|
More of a guideline really.
|
|
|
|
|
LOL
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
What's so hard about COL1, COL2, COL3?
/s
|
|
|
|
|
As punishment for that you get sent to Q&A for a week!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
If they ask for codez now I'll use those variable names!
I'm pretty certain I saw something like those in a BPCS system once... I'm still trying to erase that memory.
|
|
|
|
|
I (and I suspect many other CPers) have inherited databases with cols called Unused253, Unused254, Unused255 all with cryptic codes being used in them
|
|
|
|
|
If I find a col named Unused*, I feel free to delete it.
If I find a file in a temp folder, a file named *.tmp or *.temp, I feel free to delete it. (Most certainly after a reboot when the application creating it certainly is not running.)
Many years ago, I worked with an OS providing temp files in an elegant way: Any nameless file was deleted by the file system when closed. You could change the name of an open file, e.g. from nameless to a random name for handing it over to some other process (file name transferred through a pipe), which might open it and change back to nameless so it would be deleted when it was closed. I think that was a much more elegant solution than all these temp directories everywhere.
|
|
|
|
|
I once worked on a site where they had configured MS-Word options to do autosaves to the TEMP folder. They also had the login startup process (AUTOEXEC.BAT) clear the temp folder. This meant that if your session crashed, your active work would have fairly recently have been saved for reloading; but when you rebooted, the saved data was removed before you could use it.
|
|
|
|
|
There is an old story from the University of Copenhagen, from the days when large data files were stored on magnetic tape, and no computers had a real time clock with battery backup. So if the system crashed (and the Univac 1108 could be crashed by a single instruction!), after reboot you had to manually set the current time. Furthermore, computers were so expensive that university computing centers served sort of like a cloud service to lots of industry and commercial customers.
This huge Univac 1108 mainframe experienced a crash, and was rebooted. The operator handling it typed in the current date and time, not noticing that he had mistyped the year, to ten years into the future. This was not discovered before the cleanup procedure was run that deleted all files that hadn't been accessed for three months ... (This was quite common practice in those days).
That is not the whole story, though: You might think "But the files were stored on magnetic tape, weren't they?" They were, but Univac had defined a format for saving space on the tape and also provide much faster, direct access: All the directory information was directly available online, on disk, without having to search the tape. The tapes held the data blocks. Only. No directory information. The cleanup operation wiped out the directory information on the disk.
So they were left with a million blocks of non-deleted data. but with no information about which block belongs to which file. It was said that for some really important customers, the operators inspected the tapes "by hand" to lay out the puzzle to match blocks together (tape rolls had an ID, and some customers could find that ID from old job listings).
Our University had two similar Univacs, so our computer department had close contact with the Copenhagen guys, and the story was spread to our students. I don't know if it ever became known to media. The actual incident took place before I became a student, some time in the early/mid 1970s.
|
|
|
|
|
We had similar fun with dates:
* When an ICL 1900 booted up, its Manual EXEC asked for the date. The year format was two digits and was based at 1900 (unlike the operating system that took two digits where 65 to 99 were 1965 to 1999, 00 to 64 were 2000 to 2064). One operator entered the full year (e.g. 1982) and the Manual EXEC took the first two digits (19) as meaning 1919. That worked fine - dates for files and exofiles (data on disks not included in the operating system's filestore) were updated with dates representing 1919. When the machine was rebooted again, the next operator correctly entered the year as 82. This caused all of the files to be deleted as they were 63 years old - way outside of their expiration period.
* On an ICL SYSTEM 25, the boot sequence expected (IIRC) a date in the format nn/nn/nnnn. It then prompted the operator with a message like 'Today is Sunday. Is that correct?'. The operator had entered 01/11/1981 which was a Sunday in dd/mm/yyyy format [1st Nov] and was also a Sunday in mm/dd/yyyy format [Jan 11th]. The prompt gave the operator confidence that he had entered the date correctly, but he hadn't used the correct format.
|
|
|
|
|
string MyName => SomeOtherName;
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Don't worry, it's just a temporary thing. Next migration will change the database column names and (dis)order will be restored in universe.
Mircea
|
|
|
|
|
So, I smiled when I read this, thinking of the because it's easy and makes sense answer.
But really, this is a deeper question that depends on what language you are using and what the application interaction with the user is. I'm assuming you're comparing local variable names to the DB columns; and not accessing the actual DB object.
There are cases where this may not be best practice and maybe a case could be made to argue it is not best practice at all.
|
|
|
|
|
I assume you're not using an ORM? All the ORM's I've used (EF, Linq2SQL, Dapper, etc) have the ability to attribute the model with table and column aliases.
|
|
|
|
|
But why one should use different names? Is it not only make the things more confusing?
|
|
|
|
|
Job insurance.
|
|
|
|
|
Because the people that once designed the database gave their columns names like cicmpy (customer info company, or something like that, taken from a very popular financial system).
Or because you're dealing with TextField1, TextField2,... TextField20, DateField1, DateField2,... DateField20, etc. "because the software should be flexible." (I have to admit, the software is flexible and works miraculously well, but their API is horrible).
|
|
|
|
|
0x01AA wrote: But why one should use different names?
Certainly one reason is that databases have absolute length limits. So if you exceed that you are out of luck.
As an example the Oracle column name length limit is 30.
Additionally when database statements are constructed there are length limits on the total length of that.
One of course should not normally run into that. Which is perhaps worse because what happens is that someone uses magical coding APIs without understanding what is actually happening and then when it fails for that one odd ball case then no one can figure out what is happening.
Then there are things that happen over time. Such as a table that has a column named 'total' which even though the column is still named that, what is actually is now is the 'DailyTotal'. Column might be used in one place where in the code the attribute 'DailyTotal' is used in many places. So explaining what it actually is in every place becomes a problem.
|
|
|
|
|