3 ms·

(0) The idea is not to start without any schema but to start with one and then let it develop. In the example above, if Employees are only in one department an

(0) The idea is not to start without any schema but to start with one and then let it develop. In the example above, if Employees are only in one department and suddenly you have the situation where an employee is in more than one department, you don't need to create a link table to model that. In other words, you don't need to think, "Is this a one-to-one, one-to-many, or many-to-many relationship?" before you start, it can just emerge as you go. (1) You can find more at Kayia.org but more will be posted on the site soon. (2) A nontrivial application example is not available just yet and I agree with you that it would a great place to examine its trade-offs. The next several months will be quite busy but if you could please check in after that and I think we can eventually get you an answer you'll be quite pleased with.

catnaroek 11y ago
> In other words, you don't need to think, "Is this a one-to-one, one-to-many, or many-to-many relationship?" before you start, So, which is it: do I begin with a schema or not? If I don't need to think about the cardinality of relationships, then I don't have a schema. (My definition of “schema” is “a DBMS-enforced description of the logical structure of a database”. If I don't have to think about it, how can the DBMS enforce it?) > You can find more at Kayia.org The syntax is properly specified, but the semantics is not. Also, I keep getting lots of JavaScript errors when I try to use your website.
- david927 11y ago
  If you only want there to be one department per employee, you can constrain that relationship and the database enforces it. When an additional department is attempted to be added for an employee, it won't be allowed. If you have a list of Films, their title, release date and director, and you don't want additional columns to be allowed to be added, you can set that constraint as well. Let's say now you find out that one film has two directors (a change in relationship cardinality). If you have not constrained it, the default is to allow that to happen. You have schema. The default, though, is to let the data tell you what it is rather than the other way around. > Kayia.org The syntax is properly specified, but the semantics is not. Also, I keep getting lots of JavaScript errors when I try to use your website. There's also a lot of missing information. My apologies; fixes are coming. We didn't plan to submit this to Apply HN -- the opportunity just jumped and so did we. We should have waited and fixed those things and then submitted. Again, apologies, changes are coming.

catnaroek 11y ago

> In other words, you don't need to think, "Is this a one-to-one, one-to-many, or many-to-many relationship?" before you start, So, which is it: do I begin with a schema or not? If I don't need to think about the cardinality of relationships, then I don't have a schema. (My definition of “schema” is “a DBMS-enforced description of the logical structure of a database”. If I don't have to think about it, how can the DBMS enforce it?) > You can find more at Kayia.org The syntax is properly specified, but the semantics is not. Also, I keep getting lots of JavaScript errors when I try to use your website.

david927 11y ago
If you only want there to be one department per employee, you can constrain that relationship and the database enforces it. When an additional department is attempted to be added for an employee, it won't be allowed. If you have a list of Films, their title, release date and director, and you don't want additional columns to be allowed to be added, you can set that constraint as well. Let's say now you find out that one film has two directors (a change in relationship cardinality). If you have not constrained it, the default is to allow that to happen. You have schema. The default, though, is to let the data tell you what it is rather than the other way around. > Kayia.org The syntax is properly specified, but the semantics is not. Also, I keep getting lots of JavaScript errors when I try to use your website. There's also a lot of missing information. My apologies; fixes are coming. We didn't plan to submit this to Apply HN -- the opportunity just jumped and so did we. We should have waited and fixed those things and then submitted. Again, apologies, changes are coming.