- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It's £80+ to change by deed poll, but you can also get a solicitor to sign a declaration that you renounce your old name and will exclusively use the new name. Most solicitors will charge about £15 for that, and it's good enough s to get a passport in the new name
Admin
A quick google indicates there's a whole slew of reasons you can request a last name change, though none of them allow willy-nilly changing of last names. Dutch link: https://www.justis.nl/producten/naamswijziging/faq-achternaamswijziging/
For a first name change, apparently, you need to file a request at a court, and be assisted by a lawyer. Probably similarly requires strong reasons.
Admin
I wonder if my reason would be considered strong? I've gone by my name all my life (call it Jaloopa), then when applying for a passport last year I discovered that my birth certificate has me as just J. Apparently my parents thought the christening certificate in the name of Jaloopa was more official than the birth certificate
Admin
Probably wouldn't have been accepted here at birth; if you'd immigrated and naturalized then it would be likely you could change it during naturalization, or get it changed later.
Admin
Okay, I'll buy that, adding all those columns was "bloat-columns".
Admin
Is this really that bizarre? The product that I work on is completely built around the concept that users can define their own data points, which are represented as columns in a single table. And we stretch this out all the way to 4000 column limit that MS SQL gives us.
The first day I started at the company, I was like "why aren't you using EAV?" to which I got the whole "EAV is evil and you should never use EAV" gig (no, they didn't actually try it before). If you're wondering whether we run into data corruption issues... all the time. Every other day, we have a customer calling in because their database got corrupted and their system went down.
Admin
EAV is not evil, but it is not optimum for core system objects.
Take a payroll system I worked on: It had an employee object and a payroll object (1:1 employee), and a wage object with history. The employee object contained things like name, address, phone, birth date, SSN, employment status, and so on. The payroll object contained pay plan, full/part time status, exempt (salaried) flag, and similar such objects. The wage object contained just the wage and the date range that wage was applicable for the position, and was versioned for history.
Having that stuff stored as EAV would be silly, because the element collections for the objects are used in many programs, and assembling each object from EAV, in each program, each time it is needed, is an enormous expense (maintenance and database effort) for routine operations.
But table columns are a limited resource in every database I'm aware of. IBM DB2 for the host supports 750 columns. The idea that the user would be allowed to dynamically add columns to the table for "cat name", "house color", "organizational memberships", "ACLU member", "favorite restaurant", "favorite spa", "hair style", "likes dawn", "likes sunset", and whatever else they can think of without restriction (including misspellings, "lkies dawn") is just asking for trouble. That type of ad-hoc "good stuff to remember" is better stored as EAV.
And that's what they were doing: using columns for stuff that should have been EAV. This was a sales-contact software, and a salesman succeeds by knowing his contact's interests, likes, and dislikes. But those can be anything; they are literally as individual as humans. The are also sparse--looking at the list above that I just produced from thin air: How many of those do you think would really be answered for every contact? So, EAV--that's what they should have used.
Admin
If you're not going to join on it, search on it, filter on it, or summarise by it, you don't actually need to make it be its own column. (Some things it might still be a good idea to break out, but they're not strictly necessary.)
Admin
Yeah, some of that stuff could just go into a big CLOB or TEXT field. But I think EAV does have some advantages - it allows easier structured searching than a CLOB or TEXT field allows, in situations where dynamic alter table's are clearly not acceptable.
Admin
"... since the Intranet website was going to be taken down in a few months..." Pretty much guaranteeing that it will still be in use three years later.