If you feel that RDBMSes are not a good idea for an online game, what data and experience has led to that?

There are tons of successful games that use RDBMSes correctly, and get great performance. There are tons of instances where schema-less key/value stores end up costing more than they help, because you can't easily use secondary indices (unless you turn your "schema-less" storage into a poor man's "pseudo-schema-ed" storage.)

And vice versa -- use a RDBMS incorrectly, and you will be slow.

Regarding storing acquired skills as a bitfield (didn't see that two months ago) -- if your table is (characterId not null, skillArchery default null, skillSneaking null, skillSmithing null, ...) then most RDBMS-es will turn the NULL columns into a bit field under the covers, and you still get to marshal/de-marshal as if it were a full struct. You get "null" back for the skills you haven't unlocked, and non-null values for the skills you have a rank in. Seems like a great match to me, especially for a first iteration.

With SQL db you spend a lot of time and resources when your schema changes.

Do you have specific experience with this that you can share?

With schemaless implementations, you instead spend a lot of time debugging bugs that happen because some code puts in data in a format different than what some other code reading the data expects. The bigger your game gets, the more likely those bugs are. I'd rather take the small cost of schema updates than the lack of type checking and "have to be able to read any old version of data" problems of schemaless. That's based on specific experience I have with both, so yours may be different :-)

.

You're hitting the nail on the head: Untyped, dynamic systems are great for smaller systems and prototyping, where getting to "can this work" and trying out ideas quickly is more important than operational concerns and long-term maintenance.

Typed, static systems typically require a bit more lifting to get started in, and the benefits don't pay off until the system grows, and you're starting to maintain it and having to live with data and decisions made months and years ago, and having to understand how dozens or hundreds of modules may interact.

This is true for programming languages, for databases, for network protocols, and most other design areas in computer science.

For a start-up with a limited amount of money, looking for product/market fit, the ability to try lots of things quickly is more important than the cost of maintenance, and the code is by definition small. For an established organization, that knows who the customers are, and know what the product is and will continue to grow into, the trade-off is different. (For companies that succeed, there's this hard, harrowing time in the middle, where the company has to transition from soft/dynamic to hard/static methods, which is another topic in and of it's own :-)

It's great that you point out the limit on number of columns of many databases (typically 255, but check your specific database!)

I don't think SQL people will necessary beat anyone up for having lots of columns. After all, for a customer record, we don't create separate property tables for "name" and "email address" and "mailing address line 1." If you think this table is fine:

CREATE TABLE customer(
customer_id NOT NULL INTEGER,
name VARCHAR(255),
email VARCHAR(255),
address1 VARCHAR(255),
address2 VARCHAR(255),
mailing_code VARCHAR(255),
mailing_city VARCHAR(255),
mailing_country VARCHAR(255),
phone VARCHAR(255),
PRIMARY KEY(customer_id));

Then why is this table bad?

CREATE TABLE character(
player_id NOT NULL INTEGER,
character_id NOT NULL INTEGER,
strength INTEGER,
dexterity INTEGER,
mana INTEGER,
swords INTEGER,
polearms INTEGER,
shields INTEGER,
dodge INTEGER,
swimming INTEGER,
PRIMARY KEY(player_id, character_id));

If you specifically use MySQL/InnoDB, you can even make your tables allow adding more columns without having to update table stores, by pre-creating 255 columns as nullable, named "future_01," "future_02" and so on. Nullable columns end up only taking a bit in the record when they don't have a value, and you wouldn't be referencing them. Then, when you introduce a new skill, ALTER TABLE RENAME some future_ column to the skill you need. That's a very fast data dictionary update!

I also don't understand why serializing out of a single row would be any more or less work than serializing out of a self-join table or out of a BLOB/TEXT field. You still have to look up the string "strength" to some integer variable somewhere, and you very likely want to write that as some kind of IDL that generates code from schema, rather than manually doing it, no matter which of the options you choose.

For most smaller games, the one-row-per-character option is actually surprisingly usable, and surprisingly easy to work with. You only need to bring out the bigger guns if your design and implementation actually exceed what you can do with that initial approach.