[skill_name] field in [clan_skills] table

[reblock]

e.g. in items the owner id is taken from characters or from clans, so they cannot be same.
for augmentations - yeah, somehow that is wrong, because we already have a mapping between augId and skill id-level, so there should be no need for that in db. true.

server written by NCZ0ft has different structure, so you cannot just take data from there and migrate it to l2j. different tables, different data structure, different logic.

I already transfered all data (really ALL) from NCZ0ft database to yours. It's not a big problem (much work for analysis, but it's real).

You already have field in [items] called [loc]. So if loc = CLANWH - this is clan item (and ownerId = clanId).
Char items: SELECT * FROM items WHERE owner_id = ?d AND loc <> 'CLANWH' (?d - charId)
Clan items: SELECT * FROM items WHERE owner_id = ?d AND loc = 'CLANWH' (?d - clanId)
This way is used in NCZ0ft database.
Oh, I almost forget, why loc field has VARCHAR type and not ENUM? ENUM is much faster, because it is just INT with aliases.

[Vith]

If we wanted to be strict, there are many more examples of bad practices with L2J database. I was just giving a glance at it, and e.g.:

Code: Select all

`fish_type` int(1) NOT NULL  default '0',  -- 0 = wide, 1 = swift, 2 = ugly, 3 = box, 4 = easy_wide, 5 = easy_swift, 6 = easy_ugly, 7 = hard_wide, 8 = hard_swift, 9 = hard_ugly`fish_group` int(1) NOT NULL default '0', -- 0 = easy, 1 = normal, 2 = hard

The point is, IMHO there are more important and useful tasks than database refactoring. I mean, it is important, but with every project, due to limited resources (developers' time mostly) you need to prioritize things. Since most of database access happens during server initialization and shutdown, it would speed this processes a bit - but hey, I guess players would rather see new features and wait 5 minutes for server restart, than the other way (-:

Another advantage of having a solid-rock database, is data consistency (e.g. in the above fish part, you could make "hard_ugly" fish belonging to "easy" group). But to be honest, we recently notice a trend of moving the task of caring about data being valid from DBMS to the application itself. This gives the app better portability to other DBMS. E.g. someone already noticed there is no way with MySQL to guarantee uniqueness of IDs between tables, something that is possible e.g. with Oracle. So you can either spend thousands of $$$ for Oracle DBMS, or just move the task into the application. The former solution seems to be more common these days.

That's for a little theoretical stuff from me (-: