SaptaZapta Wrote:Actually, the issue in both cases is the structure of their database. A technical issue that's about as likely to get changed as the irrational client-server relationship.
semi-technical explanation
The database they use is composed of tables.
In this sort of database, there are two basic ways of dealing with items that can have multiple instances of related items.
For example, let's consider a vehicle license database for the DMV: They need to know about people and cars, and the relationship between them (i.e., which person owns which car(s)).
One way to do it is to have one table. Each row is for a person, and contains columns for Name and Address and such identifying information, and then information about Car1, Car2, Car3, .... How many "Car" columns do we put in this table? How many vehicles can one person own? Well, there's no legal or physical limit (other than the number of cars in existence, I suppose). But since this is a table, if we allocate 1000 columns to cars, every single row will have those cells, even if they're empty. Lots of wasted storage space. The advantage, however, is that when they pull up the row for Mr. StellarAshes, the information about all his cars is right there. No need to go looking for it elsewhere on the hdd.
The other way to do it is to have two tables. One with information about people, and one with information about vehicles. The people table contains no information about vehicles at all. The vehicles table has one row per vehicle, and that row has the ID of the car's owner. If they want to see all the cars owned by Mr. StellarAshes, they have to ask the database to fetch them all from the vehicles table. This entails some search work by the database program, and likely several reads from the hdd as it goes and finds the various bits of data wherever they were stored (at different times probably). It's a much slower process than the one-table solution. However, it does not limit the number of cars per person, and it does not waste space on empty cells.
Nexon chose to do it the first way. It helps the game run faster, but at the cost of wasted space and consequently a fairly low hard limit on "expansions" (because the space for a full inventory is pre-allocated for each and every character, even if they can't access it until they pay).
At least, this is the way I think they did it. It's the only reasonable explanation as to why they won't accept our money to expand further. No doubt someone better informed will correct me if I'm wrong.
I run a Maple database website as well as having rather extensive knowledge of PS, and having briefly went over the assembly/MsSQL databases of BMS, so believe me when I say that I do know my way around DBs. The issue I was talking about with the character slots is the incentive (or lack thereof) for Nexon to allow people to purchase additional slots.
As for the technical explanation you give, I know for sure PS uses the second method. I don't recall off the top of my head what BMS used. Also, the "speed" improvement of the first way over the second way is so miniscule (less than 1/100th of a second if indexed/keyed properly) that it's hard for me to believe Nexon (well, technically, Wizet) would do that. Then again these are the same coders who accepted item IDs from client as if they were always correct so I could be very wrong.
