Removal of TXT DBs

[Maki]

Option 1

Convert all the following databases in /db/ folder to SQL:

item_db

item_db2

mob_db

mob_db2

pet_db

pet_db2

mob_skill_db

mob_skill_db2

quest_db

produce_db

Option 2

Convert all .txt databases in /db/ folder to SQL

Option 3

No, leave them how it is (user selectable between TXT and SQL)

[mirabell]

option 1 is great and good enough BUT if we going to do Option one , We might as well do them all. It really doesn't hurt to do them all if all the main one are going to be converted anyways.

[Aeomin]

Really, no one gives any opinion and just vote?

To summarize previous rebate, those who believe TXT is easier to maintain for reasons I have no clue (maybe they don't know how to use MySQL?)

And others who favor the change (like me), believe MySQL is the way to go. Besides player db is going to ditch TXT anyways. So if you don't know how to use MySQL, that is a very bad reason.

So yeah, I would love to hear some reasons in any option you choose(bonus if you can convince others by prove it)...

[Brian]

If we go with Option 2 (convert all databases to SQL) option 1 or 2, anything where there is more than 4 item/mob tables,

I vote for a 3rd database connection/config.

Then people can have 3 SQL databases setup like:

1. rAthena database (item, mob, mob_skill, pet, produce_db, etc..)
   
2. player data (all the tables currently in main.sql, except log tables)
   
3. logs database (all the tables currently in logs.sql, plus charlog and interlog)
   

Edited January 2, 2012 by Brian

[Aeomin]

If we go with Option 2 (convert all databases to SQL), I vote for a 3rd database connection/config.

Then people can have 3 SQL databases setup like:

1. rAthena database (item, mob, mob_skill, pet, produce_db, etc..)
   
2. player data (all the tables currently in main.sql, except log tables)
   
3. logs database (all the tables currently in logs.sql, plus charlog and interlog)
   

Due to popularity, I doubt option 2 get pass =(

But hey, this organization works for option 1 too!

[Kraiser X Astral]

I would suggest option 3. Most of the people out there are already comfortable with text database. Option 3 you are also free to choose between text or sql database, its just a matter of free will.

[lecksmatt]

I would suggest option 3. Most of the people out there are already comfortable with text database. Option 3 you are also free to choose between text or sql database, its just a matter of free will.

Agreed with him, it's better to choose Option 3 since not all of the users are in favor of SQL, they only want a plain TxT server and im one of them..

TxT servers can also used in testing new stuffs coz not all stuffs that can be added on rAthena needs SQL right?

Free will guys, free will..

~Lecks

Edited January 2, 2012 by lecksmatt

[JayPee]

If we go with Option 2 (convert all databases to SQL) option 1 or 2, anything where there is more than 4 item/mob tables,

I vote for a 3rd database connection/config.

Then people can have 3 SQL databases setup like:

1. rAthena database (item, mob, mob_skill, pet, produce_db, etc..)
   
2. player data (all the tables currently in main.sql, except log tables)
   
3. logs database (all the tables currently in logs.sql, plus charlog and interlog)
   

+1 to this, I only disagree to the ditching of mob_db,mob_db2,item_db,item_db2 text coz I dont want to expose the Item and Mob database that the server use in the website or in the CP. If the mob_db,mob_db2,item_db,item_db2 will be move to a separate database then I agree of ditching the text.

[saithis]

PRO SQL:

- easier to edit

- easier to use in websites/CPs [optional]

CON SQL:

- tool needed for editing (but since txt support for the player db gets dropped, you need that anyway)

- slower serverstart (or i'm wrong here?)

please correct me if i got something wrong

i voted for option 1, but please with a 3rd database

I would suggest option 3. Most of the people out there are already comfortable with text database. Option 3 you are also free to choose between text or sql database, its just a matter of free will.

Agreed with him, it's better to choose Option 3 since not all of the users are in favor of SQL, they only want a plain TxT server and im one of them..

TxT servers can also used in testing new stuffs coz not all stuffs that can be added on rAthena needs SQL right?

Free will guys, free will..

~Lecks

txt server support will get dropped (see here), so thats no excuse.

you have to learn sql anyway, or stop hosting a ro server

If we go with Option 2 (convert all databases to SQL) option 1 or 2, anything where there is more than 4 item/mob tables,

I vote for a 3rd database connection/config.

Then people can have 3 SQL databases setup like:

1. rAthena database (item, mob, mob_skill, pet, produce_db, etc..)
   
2. player data (all the tables currently in main.sql, except log tables)
   
3. logs database (all the tables currently in logs.sql, plus charlog and interlog)
   

+1 to this, I only disagree to the ditching of mob_db,mob_db2,item_db,item_db2 text coz I dont want to expose the Item and Mob database that the server use in the website or in the CP. If the mob_db,mob_db2,item_db,item_db2 will be move to a separate database then I agree of ditching the text.

i agree with a 3rd database, but you could also make a new mysql user for your website, that has only the rights for a subset of the tables.

so even without a 3rd db, you don't have to expose all tables

Edited January 2, 2012 by saithis

[Squishyyy]

Option 2 .... it's time we got rid of txt once and for all. Honestly, I thought this was done years ago. Did you just never finish the job?

[Aeomin]

CON SQL:

- tool needed for editing (but since txt support for the player db gets dropped, you need that anyway)

- slower serverstart (or i'm wrong here?)

I need tool to edit txt based db too! Look all those comas, miss one or misalignment = fail!

Yes, slower start time, by few milliseconds. If there is a need for worry that, there are more things to worry about.

[Mercurial]

Lets move all settings to SQL , that way we can have a Admin Control Panel to adjust rAthena settings, from a website, restart from a web site

[saithis]

ok, if it's just a few milliseconds slower, then i'll change my vote to option 2 now

Lets move all settings to SQL , that way we can have a Admin Control Panel to adjust rAthena settings, from a website, restart from a web site

all except the mysql options

but a Admin Control Panel website is a very good idea

Edited January 2, 2012 by saithis

[Aeomin]

Problem with configuration files is those useful comments are gone(though I do know people tend not read them and just ask others).

[saithis]

An Admin Control Panel would solve this

and/or we could make a description in the wiki for every table

[Jonne]

An Admin Control Panel would solve this

and/or we could make a description in the wiki for every table

®Athena is an emulator. Do we really want all these third party/side projects?

[pan]

IMHO option 1 is the best one, we already have rAsql that makes extremely easier to use mySQL so I don't think anyone will have difficulties exchanging TXT servers for SQL. Plus this option would help a lot on db editing (using some tool like phpMyAdmin), creating new entries will be muuuuch easier, but it's also needed to release a db converter because there are lots of customizations available converting them manually would be a very painful job if you know what I mean.

I don't agree on converting configuration files, there're too many important commentaries there as Aeomin stated.

[Emistry]

I agree for Remove the TXT DBs....

since we are going to move to SQL based Emulator....

then...TXT is useless already....coz it is not going to be "Support" soon..

All DB will be in SQL then...as the emulator run in SQL...

So...REMOVE it xD

[Mercurial]

An Admin Control Panel would solve this

and/or we could make a description in the wiki for every table

®Athena is an emulator. Do we really want all these third party/side projects?

no but why do we have a CP for registration? why not for administration? , its optional ...

metasploit does this

[Revenant]

I concur with Brian's post. Keep text databases for game stuff and deprecate all others. I can't talk for anyone else, but in the past I definitely preferred editing plain text for mob and item databases while keeping accounts and such in SQL. It just seems like a lot of hassle given how frequently variables might be changed adjusting statistics.

[Brian]

^ I agree, "configs" are fine in text files.

"databases" might fit better in a real MySQL database instead of flat text files

(that what this topic/poll is about)

[Gepard]

DB folder is a config. Nothing is written to it at runtime, so it's not a real database.

[Aeomin]

DB folder is a config. Nothing is written to it at runtime, so it's not a real database.

read-only doesn't mean it's not database...

[Gepard]

And database (if you insist) doesn't mean "put me to SQL". TXT is easier to manipulate with. Using *.sql files will make it harder to develop, edit, compare merge into running servers etc. Editing SQL requires additional GUI tools (not everyone wants to open SQL connection or install pma) or lots of overhead (typing queries!). TXT files can be edited locally and copied over, can be put into svn and svn update will merge deploy them. SQL scripts must be manually imported into dbms - again more work... I can see absolutely no advantage of SQL over TXT in this case.

[xazax]

To make things a bit clearer.

Reason for removing TXT support of player database:

• There is individual char_server and char_server_sql, we needed double work for char server edits
  
• Each time a new system appears like mercenaries, we would need to implement both sql and txt saving/loading, increasing our workload
  
• The compiled code is actially different of a SQL and a TXT compiled servers, we need to maintain more project files, people asking for support need to provide additional information etc.
  
• Using SQL is far more flexible because of CP and web services, and should perform better, and be safer ( less likely to loose data ).
  
• They are frequently modified at the runtime.
  
• Maintenance of SQL databases are easier ( deleting old/unused logins, purging invalid data, and etc).
  
• There are TXT related bugs, and unimplemented TXT features such as mercenaries.
  

Now lets look at the db folder:

• db folder does not need maintenance from the server owners.
  
• Supporting db folder in txt format does not increase our workload much, the format is rarely changes, we do not need more project files for that etc.
  
• It is fairly easy to convert some of the dbs to SQL in case of somebody feel more confortable with that
  
• They are not modified on the fly, moreover the server does not modifies it at all.
  
• Does not have bugs or unimplemented features.
  
• Aegis also use flat text files for the same thing.
  

All in all, if somebody fond of SQL db's, he can use it. But dropping TXT support for db folder provides us (developers) only little (or almost none) decrease in our workload, but degrades eA compatibility, makes people harder to switch from eA, and causes additional workload for server owners too ( They now just need to update item_db.txt and they are done. But with SQL dbs, they need to update item_db.sql and import it afterwards, +1 step) . Moreover it makes it harder for those who used to the txt format, to do db work.

One of your reason was, it is easier to edit some dbs in SQL. Well.. if you use a GUI maybe. BUT:

• There are tools available to easily edit TXT format too ( database editors )
  
• If you feel more confortable to edit something in SQL, you are free to do it that way and export afterwards ( i.e. mass edit ).
  

Maybe you feel that db developers would have double work if we maintain 2 dbs. Well, no. They only need to maintain sql, or txt. The one they prefer. And if we provide conversion tools, they can keep updated the other one. ( I think there are some pearl script available to convert dbs, however it would be maybe better to provide binaries, it would be easier to use for all ).

That is my opinion.