4 ms·

Hey @vosper, thanks for your feedback! To clarify, what we mean by simplicity is making databases as simple to work with as using an API. An example of this is

Hey @vosper, thanks for your feedback! To clarify, what we mean by simplicity is making databases as simple to work with as using an API. An example of this is native GraphQL support within FaunaDB. We're continuing to make our database concepts like Collections easier to use and understand. I've made a note to clarify the blog post you are referencing. Collections come from a NoSQL approach, and allow users to change what's stored in data records over time. We see this as a convenient way to store data, without having to worry about specifying a schema upfront that may change over time.

vosper 7y ago
> without having to worry about specifying a schema upfront that may change over time. Thing is, there's always a schema. Code always expects data to look a particular way. Whether it's written down and enforced by the DB or not will have a great influence on your ability to reason about your system and make changes down the line. This sounds like the same mistakes of Mongo all over again. Databases that don't require and enforce schemas trade a degree of early flexibility and development speed for a future of confusion, hacks and workarounds, and lower velocity. Most people who make this tradeoff aren't aware they're making it. The rest of us use RDBMS. (I get that you work for the company and I don't expect this comment to change anything - except hopefully the mind of someone contemplating using a no-schema database)
- evanweaver 7y ago
  Optional write-time validations are on the roadmap. FaunaDB does enforce unique constraints via indexes already. FaunaDB is temporal as well and people don't really enjoy migrating the past, so it has to be a little different than a traditional RDBMS schema. But ultimately it will be more flexible as well.

4 ms·

Hey @vosper, thanks for your feedback! To clarify, what we mean by simplicity is making databases as simple to work with as using an API. An example of this is

by telligent 7y ago

vosper 7y ago
> without having to worry about specifying a schema upfront that may change over time. Thing is, there's always a schema. Code always expects data to look a particular way. Whether it's written down and enforced by the DB or not will have a great influence on your ability to reason about your system and make changes down the line. This sounds like the same mistakes of Mongo all over again. Databases that don't require and enforce schemas trade a degree of early flexibility and development speed for a future of confusion, hacks and workarounds, and lower velocity. Most people who make this tradeoff aren't aware they're making it. The rest of us use RDBMS. (I get that you work for the company and I don't expect this comment to change anything - except hopefully the mind of someone contemplating using a no-schema database)
- evanweaver 7y ago
  Optional write-time validations are on the roadmap. FaunaDB does enforce unique constraints via indexes already. FaunaDB is temporal as well and people don't really enjoy migrating the past, so it has to be a little different than a traditional RDBMS schema. But ultimately it will be more flexible as well.