4 ms·

> no schema Do you read them back? Does your code expect property "X" to be on a "Player" object? Do you put a check everywhere for when it doesn't? Do you hav

> no schema Do you read them back? Does your code expect property "X" to be on a "Player" object? Do you put a check everywhere for when it doesn't? Do you have default value for objects that were created before new property was added? All that work could've been done by your database (which is probably has some kind of JSON implementation anyways), but somehow it's a "no-brainer" to implement data consistency at app-level. Okay.

scarface74 9y ago
Does your code expect property "X" to be on a "Player" object? Do you put a check everywhere for when it doesn't? Do you have default value for objects that were created before new property was added Why would you put checks everywhere a properly written code base would have one module/service that handles the player object and every consumer would use that one module.
- aidos 9y ago
  There have to be some checks, somewhere. Even though it's limited to one module, you can get temporal inconsistencies. e.g. you add a new field and an application level default, then later that default is changed. Now there's no notion of which default the docs that never had the property should be using. Sure, you just need to patch the old docs to set the property where it's missing. But the GPs point was that by not keeping a consistent schema you end up moving the definition of the data into the application, and you need to be very aware of the trade-off. Personally I'm really happy using postgres and dropping into jsonb when it's the correct model to use. It's the best of both worlds as far as I'm concerned. I've built and worked on systems using nosql solutions that have been migrated back to sql and the data inconsistencies we found have made me very wary of having a primary datastore that doesn't enforce strict constraints. Though, everybody's use case is different.
  - scarface74 9y ago
    But the GPs point was that by not keeping a consistent schema you end up moving the definition of the data into the application, and you need to be very aware of the trade-off. Why wouldn't the defaults be in the application? Why wouldn't it be treated like any other piece of business logic in code that should be unit tested? That being said, I only caught the NoSQL religion about six months ago when I started using Mongo. But SQL Server 2016 has such great support for JSON natively, as long as I'm spending other people's money, I prefer having the best of both worlds.
    - elmigranto 9y ago
      > Why wouldn't the defaults be in the application? Why wouldn't it be treated like any other piece of business logic in code that should be unit tested? How about we check our data in the place where it lives given how very robust and mature products that do that were already written, tested, and used in production by literally thousands of people for decades.
      - scarface74 9y ago
        How about we check our data in the place where it lives given how very robust and mature products that do that were already written, tested, and used in production by literally thousands of people for decades. So by "checking data" can we check all of the business constraints?
        elmigranto 9y ago
        Yes. If you really want to. Definetly stuff like presence of fields and their basic sanity (string not being empty or within a certain length), date intervals, uniqueness of certain fields or combinations, etc. You can go as far as you want, really; but like with most cases, when there's a range of possibilities, both extremes are probably a wrong answer.
- deleted 9y ago
  [deleted]
Kiro 9y ago
Yes, I read them back as a JS object in whole on login. A few things are mandatory (hp, position) but most are optional and are only checked where needed. if (player.hasSomeProp) { doStuff(player); } With your suggestion I would have a table with 200 fields and would probably have to add a lot of related tables since some of the props are arrays, objects etc. I also would lose the ability to just load the player as is (player = documentFromDB). With "no-brainer" I mean it doesn't take any effort when developing since the representation of the player object in runtime is exactly the same as it's stored in the database.
- pythonaut_16 9y ago
  I don't know anything about your game but I wonder if you could use SQLite to a similar effect. If you just want things as JS objects, you could have a Player table with a column for playerID and a column for the JSON string. I'm not saying you shouldn't use Mongo/NoSQL, I just think SQLite is an interesting potential choice. (e.g. https://sqlite.org/appfileformat.html https://sqlite.org/appfileformat.html)
- elmigranto 9y ago
  I wasn't really suggesting anything, but if I were, Postgres and its binary JSON (`jsonb`) would be there alongside with full and easy indexing support and other SQL nicities like constraints, triggers, transactions, custom procedures, etc. There are also excellent out-of-the-box support for arrays, enums, custom types, and JS procedures if you so desire. All that comes with consistent syntax, great aggregation functions, JOINs; and all those 43 years of advancement mentioned in general. Read the docs, you'll be amazed with what you're missing :) General overview https://www.postgresql.org/docs/current/static/tutorial.html https://www.postgresql.org/docs/current/static/tutorial.html JSON support specifically https://www.postgresql.org/docs/current/static/datatype-json.html https://www.postgresql.org/docs/current/static/datatype-json...

scarface74 9y ago

Does your code expect property "X" to be on a "Player" object? Do you put a check everywhere for when it doesn't? Do you have default value for objects that were created before new property was added Why would you put checks everywhere a properly written code base would have one module/service that handles the player object and every consumer would use that one module.

aidos 9y ago
There have to be some checks, somewhere. Even though it's limited to one module, you can get temporal inconsistencies. e.g. you add a new field and an application level default, then later that default is changed. Now there's no notion of which default the docs that never had the property should be using. Sure, you just need to patch the old docs to set the property where it's missing. But the GPs point was that by not keeping a consistent schema you end up moving the definition of the data into the application, and you need to be very aware of the trade-off. Personally I'm really happy using postgres and dropping into jsonb when it's the correct model to use. It's the best of both worlds as far as I'm concerned. I've built and worked on systems using nosql solutions that have been migrated back to sql and the data inconsistencies we found have made me very wary of having a primary datastore that doesn't enforce strict constraints. Though, everybody's use case is different.
- scarface74 9y ago
  But the GPs point was that by not keeping a consistent schema you end up moving the definition of the data into the application, and you need to be very aware of the trade-off. Why wouldn't the defaults be in the application? Why wouldn't it be treated like any other piece of business logic in code that should be unit tested? That being said, I only caught the NoSQL religion about six months ago when I started using Mongo. But SQL Server 2016 has such great support for JSON natively, as long as I'm spending other people's money, I prefer having the best of both worlds.
  - elmigranto 9y ago
    > Why wouldn't the defaults be in the application? Why wouldn't it be treated like any other piece of business logic in code that should be unit tested? How about we check our data in the place where it lives given how very robust and mature products that do that were already written, tested, and used in production by literally thousands of people for decades.
    - scarface74 9y ago
      How about we check our data in the place where it lives given how very robust and mature products that do that were already written, tested, and used in production by literally thousands of people for decades. So by "checking data" can we check all of the business constraints?
      - elmigranto 9y ago
        Yes. If you really want to. Definetly stuff like presence of fields and their basic sanity (string not being empty or within a certain length), date intervals, uniqueness of certain fields or combinations, etc. You can go as far as you want, really; but like with most cases, when there's a range of possibilities, both extremes are probably a wrong answer.
deleted 9y ago
[deleted]

Kiro 9y ago

Yes, I read them back as a JS object in whole on login. A few things are mandatory (hp, position) but most are optional and are only checked where needed. if (player.hasSomeProp) { doStuff(player); } With your suggestion I would have a table with 200 fields and would probably have to add a lot of related tables since some of the props are arrays, objects etc. I also would lose the ability to just load the player as is (player = documentFromDB). With "no-brainer" I mean it doesn't take any effort when developing since the representation of the player object in runtime is exactly the same as it's stored in the database.

pythonaut_16 9y ago
I don't know anything about your game but I wonder if you could use SQLite to a similar effect. If you just want things as JS objects, you could have a Player table with a column for playerID and a column for the JSON string. I'm not saying you shouldn't use Mongo/NoSQL, I just think SQLite is an interesting potential choice. (e.g. https://sqlite.org/appfileformat.html https://sqlite.org/appfileformat.html)
elmigranto 9y ago
I wasn't really suggesting anything, but if I were, Postgres and its binary JSON (`jsonb`) would be there alongside with full and easy indexing support and other SQL nicities like constraints, triggers, transactions, custom procedures, etc. There are also excellent out-of-the-box support for arrays, enums, custom types, and JS procedures if you so desire. All that comes with consistent syntax, great aggregation functions, JOINs; and all those 43 years of advancement mentioned in general. Read the docs, you'll be amazed with what you're missing :) General overview https://www.postgresql.org/docs/current/static/tutorial.html https://www.postgresql.org/docs/current/static/tutorial.html JSON support specifically https://www.postgresql.org/docs/current/static/datatype-json.html https://www.postgresql.org/docs/current/static/datatype-json...