6 ms·

hell no, it's been a breath of really fresh air for us, we've been building all sorts of things, no problems so far. (including logging several millions of requ

hell no, it's been a breath of really fresh air for us, we've been building all sorts of things, no problems so far. (including logging several millions of requests per day and performing distributed map reduce for all sorts of statistical models on a tiny 3 machine "cluster" we run on AWS, I hope I never have to go back to modifying schemas again, so much simpler to run and build with this mindset)

vyrotek 14y ago
> I hope I never have to go back to modifying schemas again Honest question. Do you actually leverage the schemaless nature of MongoDB? Not 'worrying' about managing schemas is one thing, but actually leveraging the fact that your objects can have different fields is another. I have worked on projects that did need to store objects with different fields together but it seems to be a rare case. From what I've seen, most projects actually have pretty standard objects with specific fields. People just don't like feeling constrained but in the end I don't think managing a schema is difficult at all. I actually like the safety and performance you get when you put in the effort. I think the single most useful thing to see when starting a new dev job somewhere are the database schemas. If done properly, it will essentially tell you the story of that company and their data. You can think up questions and get answers such as "Is it possible for a Customer to have multiple Orders? Can a product have more than one Review?" (Stupid examples but they illustrate the kinds of relationships which are asked about all the time).
- dmytton 14y ago
  Flexibility is useful in development. Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement.
  - vyrotek 14y ago
    In the enterprise world (at least in the Microsoft world) we have tools to manage these sorts of things. The one I'm currently using even for my small pet projects is called SQL Server Data Tools[1]. You basically just have to modify the original table creation scripts (add a column or whatever) and it actually generates all the change scripts for you. Even if the change is complex it handles making temp tables and transferring the data into the new table. It also notifies you and lets you handle cases where the change may lead to data loss. I guess my point is that the SQL world is still innovating but it doesn't get that much attention. Unless I have a specific use-case for storing similar entities together with different fields then a schemaless DB is not the right tool for the job. [1]http://msdn.microsoft.com/en-us/data/tools.aspx http://msdn.microsoft.com/en-us/data/tools.aspx
  - flatline3 14y ago
    > Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement. Instead, you're writing a bunch of code to deal with data that may be in the old format, or may be in the new format, or may be in the new-new format. I don't see that as an improvement.
    - prodigal_erik 14y ago
      In practice, you're writing code that has to deal with records that were updated by versions 3, 5, and 7 of your code but not 4 or 6. After a few years you can be sure somebody got it wrong at some point, and now you have records in a few out of the 2^n states where not even the developers can anticipate the system's behavior. The fix is to make ALTER incremental and less painful, not to stop writing down and checking your schema.
      - jeltz 14y ago
        And both MySQL and PostgreSQL have put in work to make ALTER less painful by reducing the situations where a full table rewrite is necessary. In PostgreSQL you can both add and remove columns without the table being rewritten as long as you do not set a default value. You can also increase the lengths of varchars without any rewrite.
- lmm 14y ago
  What I like is not the absence of a schema (because as you say there usually is one), but not having to fit it into the 2D SQL table model. An obvious case in when you have a many-to-one field that only ever contains a small number of values (e.g. a person's nationality); in a traditional SQL database my choices are make a separate table for it, or use a database-specific custom datatype (which never seem to be fully supported). In something like mongoDB I can just put a list in that field of the document.

vyrotek 14y ago

> I hope I never have to go back to modifying schemas again Honest question. Do you actually leverage the schemaless nature of MongoDB? Not 'worrying' about managing schemas is one thing, but actually leveraging the fact that your objects can have different fields is another. I have worked on projects that did need to store objects with different fields together but it seems to be a rare case. From what I've seen, most projects actually have pretty standard objects with specific fields. People just don't like feeling constrained but in the end I don't think managing a schema is difficult at all. I actually like the safety and performance you get when you put in the effort. I think the single most useful thing to see when starting a new dev job somewhere are the database schemas. If done properly, it will essentially tell you the story of that company and their data. You can think up questions and get answers such as "Is it possible for a Customer to have multiple Orders? Can a product have more than one Review?" (Stupid examples but they illustrate the kinds of relationships which are asked about all the time).

dmytton 14y ago
Flexibility is useful in development. Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement.
- vyrotek 14y ago
  In the enterprise world (at least in the Microsoft world) we have tools to manage these sorts of things. The one I'm currently using even for my small pet projects is called SQL Server Data Tools[1]. You basically just have to modify the original table creation scripts (add a column or whatever) and it actually generates all the change scripts for you. Even if the change is complex it handles making temp tables and transferring the data into the new table. It also notifies you and lets you handle cases where the change may lead to data loss. I guess my point is that the SQL world is still innovating but it doesn't get that much attention. Unless I have a specific use-case for storing similar entities together with different fields then a schemaless DB is not the right tool for the job. [1]http://msdn.microsoft.com/en-us/data/tools.aspx http://msdn.microsoft.com/en-us/data/tools.aspx
- flatline3 14y ago
  > Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement. Instead, you're writing a bunch of code to deal with data that may be in the old format, or may be in the new format, or may be in the new-new format. I don't see that as an improvement.
  - prodigal_erik 14y ago
    In practice, you're writing code that has to deal with records that were updated by versions 3, 5, and 7 of your code but not 4 or 6. After a few years you can be sure somebody got it wrong at some point, and now you have records in a few out of the 2^n states where not even the developers can anticipate the system's behavior. The fix is to make ALTER incremental and less painful, not to stop writing down and checking your schema.
    - jeltz 14y ago
      And both MySQL and PostgreSQL have put in work to make ALTER less painful by reducing the situations where a full table rewrite is necessary. In PostgreSQL you can both add and remove columns without the table being rewritten as long as you do not set a default value. You can also increase the lengths of varchars without any rewrite.
lmm 14y ago
What I like is not the absence of a schema (because as you say there usually is one), but not having to fit it into the 2D SQL table model. An obvious case in when you have a many-to-one field that only ever contains a small number of values (e.g. a person's nationality); in a traditional SQL database my choices are make a separate table for it, or use a database-specific custom datatype (which never seem to be fully supported). In something like mongoDB I can just put a list in that field of the document.