Second Life Forums Archive - They say name changes aren't allowed... Ah, I have an idea!

Alidar Moxie

Registered User

Join date: 2 Dec 2005

Posts: 47

04-05-2007 10:50

From: someone

The thing with a name history is that it is part of the account data, so could be stored with the rest of the data. A seperated list can work very well when reading the data is more common than searching the data. Whether access is restricted to Lindens, or there is a "previously known as" field in profiles, it eliminates joins and searches across multiple tables/DBs, and the need for an ever expanding table to store the histories.
Using a list seperated by \n saves on computation elsewhere as the list can simply be displayed without parsing, this would work well when displaying in profiles.

The issue I have had with my users on this type of implementation is that it is either restrictive to the number of 'records' the field can hold (a column only has so many characters in its width) or it ends up using as much disk space as the other table you would use for a correct design (if you use a 'text' column for instance, you could end up with an extremely large set of data trying to be read into RAM). This also assumes that you don't mind about standard database design (each column is a DISTINCT set of data), which can be sacrificed for application design, but not a whim.

I have a feeling you would be searching that data more than you think. I doubt you would want people signing up with old resident names for instance. Also, I can see many instances where, for example you see printed name of a resident somewhere outside SL and you want to see who they are, an indexed history table would be much more handy (having a separate table with an index would keep you from having to do a full table scan like you would have to do with a 'history' column.)

I would imagine that the only things related to this I would (personally) keep with the user's main data are a) How many times have they changed their name and b) when did they change their name last. The first could be calculated, but would be nice if prepopulated for reporting and the second would be asked for almost as soon as you made this feature available so why not included it?

These are just some ideas based on about the 10 minutes I have spent thinking about it, but these are the things I am paid to think about so I am sure I could think of other pros and cons.

Oh,

From: someone

With the addition of triggers in MySQL5, it could still remain as one query with a cached trigger performing the second (which would possibly be more efficient).

I am glad that a MySQL developer is thinking of these when they are working (so many do not), but keep in mind that triggers do not automatically add to efficiency unless you count simply code and easier to maintain business rules an efficiency. A trigger instead of an SQL statement still translates, generally, to the same SQL statement at some point now with the overhead of the database engine deciding if and when the SQL statement needs to run.

Tegg Bode

FrootLoop Roo Overlord

Join date: 12 Jan 2007

Posts: 5,707

04-05-2007 14:59

From: Sly Spicoli

The question that begs for an answer for me is, why would you want to change your name?

Well when roleplaying I like to use different names for different settings, example SciFi & Medievil, or I run NPC characters for the main characters to intereact with, rather than just change their name and look, I instead create more & more alts with different names and have to keep transfering the wardrobe/equipment around.

$500 for a name change, forget it!

Perhaps what we need is being able to change your displayed name but not your real name, this make playing masked superhero secret identities possible too, but this LL said they were going to do it somehow well over 6 months ago.

Mattie Hansen

Registered User

Join date: 19 Feb 2006

Posts: 52

Poll

04-06-2007 05:51

Uhmmm how many chances to have your inventory still as it is after a name change?

Guess how many accounts after a name change would lose their whole inventory for an simple mistake like forgetting a checkbox before pressing the *magic* "update all" button ^^

Argent Stonecutter

Emergency Mustelid

Join date: 20 Sep 2005

Posts: 20,263

04-06-2007 06:11

From: Sly Spicoli

The question that begs for an answer for me is, why would you want to change your name?

Because you created a character with a name you don't like, but it's got a bunch of inventory you don't want to lose.

Changing the name shouldn't cause a huge burden on the game, since the UUID and not the name is the actual identity.

If changing the name is too much of a problem, how about an option to merge two accounts, with the inventories and properties combined into one?

Argent Stonecutter

Emergency Mustelid

Join date: 20 Sep 2005

Posts: 20,263

04-06-2007 06:16

From: Alidar Moxie

I'm a DBA/Database App developer and one thing we always have to keep in mind is keeping a history. If you changed your name you had better believe that LL would want to keep track of your 'previous' names and unless they are going limit you to a small number of changes they would probably need several tables to keep track of the history, adding to the foot print of the database.

Huh?

CODE


CREATE TABLE NAME_HISTORY (
    UUID VARCHAR,
    NEW_NAME VARCHAR,
    TIME TIMESTAMP
);
CREATE INDEX NAME_HISTORY_UUID ON NAME_HISTORY(UUID);

One table, no triggers required. It would rarely be accessed... they'd really only need it for auditing. There's more database load involved in uploading a five second sound clip or editing a notecard.

From: someone

I have a feeling you would be searching that data more than you think. I doubt you would want people signing up with old resident names for instance. Also, I can see many instances where, for example you see printed name of a resident somewhere outside SL and you want to see who they are, an indexed history table would be much more handy (having a separate table with an index would keep you from having to do a full table scan like you would have to do with a 'history' column.)

Old resident names are not a problem, because you don't choose the last name and there would be no need to track anything more than the first name chosen for a currently available last name. They already do this separately from the account database, because if you abort a signup that first name is no longer available... even if no account was created.

I don't see that it should even be necessary for anyone but Linden Labs to be able to search on old names.

They say name changes aren't allowed... Ah, I have an idea!
Alidar Moxie Registered User Join date: 2 Dec 2005 Posts: 47	04-05-2007 10:50 From: someone The thing with a name history is that it is part of the account data, so could be stored with the rest of the data. A seperated list can work very well when reading the data is more common than searching the data. Whether access is restricted to Lindens, or there is a "previously known as" field in profiles, it eliminates joins and searches across multiple tables/DBs, and the need for an ever expanding table to store the histories. Using a list seperated by \n saves on computation elsewhere as the list can simply be displayed without parsing, this would work well when displaying in profiles. The issue I have had with my users on this type of implementation is that it is either restrictive to the number of 'records' the field can hold (a column only has so many characters in its width) or it ends up using as much disk space as the other table you would use for a correct design (if you use a 'text' column for instance, you could end up with an extremely large set of data trying to be read into RAM). This also assumes that you don't mind about standard database design (each column is a DISTINCT set of data), which can be sacrificed for application design, but not a whim. I have a feeling you would be searching that data more than you think. I doubt you would want people signing up with old resident names for instance. Also, I can see many instances where, for example you see printed name of a resident somewhere outside SL and you want to see who they are, an indexed history table would be much more handy (having a separate table with an index would keep you from having to do a full table scan like you would have to do with a 'history' column.) I would imagine that the only things related to this I would (personally) keep with the user's main data are a) How many times have they changed their name and b) when did they change their name last. The first could be calculated, but would be nice if prepopulated for reporting and the second would be asked for almost as soon as you made this feature available so why not included it? These are just some ideas based on about the 10 minutes I have spent thinking about it, but these are the things I am paid to think about so I am sure I could think of other pros and cons. Oh, From: someone With the addition of triggers in MySQL5, it could still remain as one query with a cached trigger performing the second (which would possibly be more efficient). I am glad that a MySQL developer is thinking of these when they are working (so many do not), but keep in mind that triggers do not automatically add to efficiency unless you count simply code and easier to maintain business rules an efficiency. A trigger instead of an SQL statement still translates, generally, to the same SQL statement at some point now with the overhead of the database engine deciding if and when the SQL statement needs to run.
Tegg Bode FrootLoop Roo Overlord Join date: 12 Jan 2007 Posts: 5,707	04-05-2007 14:59 From: Sly Spicoli The question that begs for an answer for me is, why would you want to change your name? Well when roleplaying I like to use different names for different settings, example SciFi & Medievil, or I run NPC characters for the main characters to intereact with, rather than just change their name and look, I instead create more & more alts with different names and have to keep transfering the wardrobe/equipment around. $500 for a name change, forget it! Perhaps what we need is being able to change your displayed name but not your real name, this make playing masked superhero secret identities possible too, but this LL said they were going to do it somehow well over 6 months ago.
Mattie Hansen Registered User Join date: 19 Feb 2006 Posts: 52	Poll 04-06-2007 05:51 Uhmmm how many chances to have your inventory still as it is after a name change? Guess how many accounts after a name change would lose their whole inventory for an simple mistake like forgetting a checkbox before pressing the magic "update all" button ^^
Argent Stonecutter Emergency Mustelid Join date: 20 Sep 2005 Posts: 20,263	04-06-2007 06:11 From: Sly Spicoli The question that begs for an answer for me is, why would you want to change your name? Because you created a character with a name you don't like, but it's got a bunch of inventory you don't want to lose. Changing the name shouldn't cause a huge burden on the game, since the UUID and not the name is the actual identity. If changing the name is too much of a problem, how about an option to merge two accounts, with the inventories and properties combined into one?
Argent Stonecutter Emergency Mustelid Join date: 20 Sep 2005 Posts: 20,263	04-06-2007 06:16 From: Alidar Moxie I'm a DBA/Database App developer and one thing we always have to keep in mind is keeping a history. If you changed your name you had better believe that LL would want to keep track of your 'previous' names and unless they are going limit you to a small number of changes they would probably need several tables to keep track of the history, adding to the foot print of the database. Huh? CODE CREATE TABLE NAME_HISTORY ( UUID VARCHAR, NEW_NAME VARCHAR, TIME TIMESTAMP ); CREATE INDEX NAME_HISTORY_UUID ON NAME_HISTORY(UUID); One table, no triggers required. It would rarely be accessed... they'd really only need it for auditing. There's more database load involved in uploading a five second sound clip or editing a notecard. From: someone I have a feeling you would be searching that data more than you think. I doubt you would want people signing up with old resident names for instance. Also, I can see many instances where, for example you see printed name of a resident somewhere outside SL and you want to see who they are, an indexed history table would be much more handy (having a separate table with an index would keep you from having to do a full table scan like you would have to do with a 'history' column.) Old resident names are not a problem, because you don't choose the last name and there would be no need to track anything more than the first name chosen for a currently available last name. They already do this separately from the account database, because if you abort a signup that first name is no longer available... even if no account was created. I don't see that it should even be necessary for anyone but Linden Labs to be able to search on old names.

Welcome to the Second Life Forums Archive

They say name changes aren't allowed... Ah, I have an idea!