Преглед на файлове

BETA: Updated SQL Documentation a bit.

MELERIX преди 13 години
родител
ревизия
43c29a7698

+ 3 - 0
L2J_DataPack_BETA/dist/sql/community/documentation.txt

@@ -0,0 +1,3 @@
+This directory contains tables required by the Community Server.
+
+Eventually, additional SQL scripts are locates in: custom/mods/updates folders.

+ 4 - 12
L2J_DataPack_BETA/dist/sql/community/updates/documentation.txt

@@ -1,14 +1,6 @@
-Any cummulative SQL update should be named like that:
+Any SQL Update should be named like this:
 
-YYYYMMDDupdate(_s).sql
+YYYYMMDDupdate.sql
 
-For example, if only one update is done in a single day, let's say on January 1, 2008, then the
-file shall be named:
-20080101update.sql
-
-However, if a more than one updates are all done on the same day, a sequence number will be added:
-20080101update.sql
-20080101update_1.sql
-20080101update_2.sql
-20080101update_3.sql
-etc...
+For example, at day 5 and January 1 from 2008, then file should be named:
+20080105update.sql

+ 12 - 7
L2J_DataPack_BETA/dist/sql/documentation.txt

@@ -1,19 +1,24 @@
-This directory contains table definitions and data dumps you need to import into your L2J login and server databases in order to run an L2J server. Additionally, there are directories whose content serve different purposes. You should read documentation.txt files included inside these directories for further explanation about them.
+This directory contains tables needed for L2J "cs", ls and "gs" DataBases in order to run an L2J Server.
 
-For community board related SQL files, please refer to the cb_sql directory (located at the same level this directory resides)
+Additionally, there are directories whose content serve different purposes.
+You should read documentation.txt files included inside these directories for further explanation about them.
 
 In general, and unless otherwise stated by specific conventions or guidelines the following tips should be considered:
 
 - File names should be made by using underscore_separation, instead of camelCase.
 
-- Field names should be made by using camelCase, instead of underscore_separation. This is not (totally) arbitrary, but trying to keep an acceptable balance between name length, readability, and intuitive model perception.
+- Field names should be made by using camelCase, instead of underscore_separation.
+  This is not (totally) arbitrary, but trying to keep an acceptable balance between name length, readability, and intuitive model perception.
 
-- Field types should be defined according to the actual domain they're meant to describe. Said in other words, we shouldn't have atrocities such as INTEGER(14) for 'level' just because somebody was too lazy to check column ranges in a manual and preferred to be on the safe side by guessing ;)
+- Field types should be defined according to the actual domain they're meant to describe.
+  Said in other words, we shouldn't have atrocities such as int(14) for 'level' just because somebody was too lazy to check column ranges in a manual and preferred to be on the safe side by guessing ;)
 
-- Further, when specifying a numeric type, INTEGER or its variations should be chosen instead of DECIMAL(M,0).
+- Further, when specifying a numeric type, INT or its variations should be chosen instead of DECIMAL(M,0).
 
-- Since L2J supports MySQL as its one and only data management backend, we should not hesitate to introduce any standards extension or column type MySQL provides as a non-portable feature. This statement applies particularly when we could obtain any gain either from a readability, code maintenance or system performance perspective.
+- Since L2J supports MySQL as its one and only data management backend, we should not hesitate to introduce any standards extension or column type MySQL provides as a non-portable feature.
+  This statement applies particularly when we could obtain any gain either from a readability, code maintenance or system performance perspective.
 
-- During data dump queries, no quotes should be used for numeric values and spaces after field separation commas should be ommited. This is in order to reduce file sizes.
+- During data dump queries, no quotes should be used for numeric values and spaces after field separation commas should be ommited.
+  This is in order to reduce file sizes.
 
 - Comments should be used at the developers discretion, to either serve as separators between structure and data, description of the ingame meaning of an statement or any other form of documentation intended to help administrators to understand the way they should use a table, or how could it be customized.

+ 2 - 2
L2J_DataPack_BETA/dist/sql/game/documentation.txt

@@ -1,3 +1,3 @@
-This directory contains gameserver related data. Login related data resides in ../login. Community board dumps are kept in ../../cb_sql
+This directory contains tables required by the Game Server.
 
-Updates and customization/mod scripts are held in separate folders. Please refer to the respective documentation.txt files for further details.
+Eventually, additional SQL scripts are locates in: custom/mods/updates folders.

+ 1 - 1
L2J_DataPack_BETA/dist/sql/game/rainbowsprings_attacker_list.sql

@@ -1,5 +1,5 @@
 CREATE TABLE IF NOT EXISTS `rainbowsprings_attacker_list` (
   `clanId` int(10) DEFAULT NULL,
   `war_decrees_count` double(20,0) DEFAULT NULL,
-  KEY `clanid` (`clanid`),
+  KEY `clanid` (`clanid`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

+ 5 - 15
L2J_DataPack_BETA/dist/sql/game/updates/documentation.txt

@@ -1,18 +1,8 @@
-For a while, cummulative updates were here without a naming convention, just piling.
+Any SQL Update should be named like this:
 
-During the Kamael release we collected them all in a single file (see deprecated).
+YYYYMMDDupdate.sql
 
-Any cummulative SQL update from now on, should be named like that:
+For example, at day 5 and January 1 from 2008, then file should be named:
+20080105update.sql
 
-YYYYMMDDupdate(_s).sql
-
-For example, if only one update is done in a single day, let's say on January 1, 2008, then the
-file shall be named:
-20080101update.sql
-
-However, if a more than one updates are all done on the same day, a sequence number will be added:
-20080101update.sql
-20080101update_1.sql
-20080101update_2.sql
-20080101update_3.sql
-etc...
+During the Kamael release we collected them all in a single file (see "deprecated" folder).

+ 3 - 1
L2J_DataPack_BETA/dist/sql/login/documentation.txt

@@ -1 +1,3 @@
-This directory contains database dump and definitions required by the login server. Eventually, login related updates, customization/mod scripts might get added on a separate folder.
+This directory contains tables required by the Login Server.
+
+Eventually, additional SQL scripts are locates in: custom/mods/updates folders.

+ 6 - 0
L2J_DataPack_BETA/dist/sql/login/updates/documentation.txt

@@ -0,0 +1,6 @@
+Any SQL Update should be named like this:
+
+YYYYMMDDupdate.sql
+
+For example, at day 5 and January 1 from 2008, then file should be named:
+20080105update.sql

+ 1 - 1
L2J_DataPack_BETA/dist/sql/maintenance/documentation.txt

@@ -14,7 +14,7 @@ repair or recovery tasks whenever they needed to.
 
 Any SQL maintenance should be named like that:
 
-YYYYMMDDmaintenance(_s).sql
+YYYYMMDDmaintenance.sql
 
 See the updates directory documentation for further details of the naming convention.