Maki Posted January 1, 2012 Posted January 1, 2012 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) 1
mirabell Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 (edited) 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: rAthena database (item, mob, mob_skill, pet, produce_db, etc..) player data (all the tables currently in main.sql, except log tables) logs database (all the tables currently in logs.sql, plus charlog and interlog) Edited January 2, 2012 by Brian 3
Aeomin Posted January 2, 2012 Posted January 2, 2012 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: rAthena database (item, mob, mob_skill, pet, produce_db, etc..) player data (all the tables currently in main.sql, except log tables) 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 Posted January 2, 2012 Posted January 2, 2012 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. 1
lecksmatt Posted January 2, 2012 Posted January 2, 2012 (edited) 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 Posted January 2, 2012 Posted January 2, 2012 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: rAthena database (item, mob, mob_skill, pet, produce_db, etc..) player data (all the tables currently in main.sql, except log tables) 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. 2
saithis Posted January 2, 2012 Posted January 2, 2012 (edited) 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: rAthena database (item, mob, mob_skill, pet, produce_db, etc..) player data (all the tables currently in main.sql, except log tables) 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 1
Squishyyy Posted January 2, 2012 Posted January 2, 2012 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? 1
Aeomin Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 (edited) 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 Posted January 2, 2012 Posted January 2, 2012 Problem with configuration files is those useful comments are gone(though I do know people tend not read them and just ask others).
saithis Posted January 2, 2012 Posted January 2, 2012 An Admin Control Panel would solve this and/or we could make a description in the wiki for every table
Jonne Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 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 Posted January 2, 2012 Posted January 2, 2012 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. 1
Brian Posted January 2, 2012 Posted January 2, 2012 ^ 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) 1
Gepard Posted January 2, 2012 Posted January 2, 2012 DB folder is a config. Nothing is written to it at runtime, so it's not a real database. 4
Aeomin Posted January 3, 2012 Posted January 3, 2012 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 Posted January 3, 2012 Posted January 3, 2012 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. 4
xazax Posted January 3, 2012 Posted January 3, 2012 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. 7
Recommended Posts