http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Justin & @Steve - RavenDB can actually work with full temporal and bitemporal data using https://github.com/mj1856/RavenDB-TemporalVersioning http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment18http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment18Fri, 29 Mar 2013 21:13:00 GMTI wrote up something similar last year, but I refer to them as Relationships or References. http://www.philliphaydon.com/2012/07/ravendb-what-am-i-persisting-what-am-i-querying-part-2/http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment17http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment17Fri, 01 Mar 2013 00:59:06 GMTGene, In any such scenarios, you usually have the product id as well as any other pertinent information.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment16http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment16Thu, 28 Feb 2013 06:57:37 GMTI have to agree with all those who think snapshotting data is a poor attempt to fix the issue of a changing product dimension. It may prevent changes to the product data from corrupting the line items table, but it slams the door on a lot of other likely needs (e.g. tracking sales of the same product across name changes, analyzing price change effects on sales, etc.). If your particular application doesn't need that kind of referential integrity, then fine, but for something like the example, You Are Gonna Need It (and will be poorly positioned to get it).http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment15http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment15Wed, 27 Feb 2013 17:43:51 GMTTemporal data is no excuse for denormalizing or removing FK's. This problem was solved in the late 90's for relational databases using bitemporal tables. Read http://www.cs.arizona.edu/~rts/tdbbook.pdf if you want to implement orders with products while still being able to see the product as it was at the time of the order or as it is now or any time in between without duplicating data elements in multiple places. Oracle, DB2 and Teradata all have the SQL temporal standards implemented so you don't have to do it manually.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment14http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment14Wed, 27 Feb 2013 16:18:50 GMTI really dislike these inter-aggregate FKs in RDBMS because it's so common to see someone generate an EF (or LLBLGen, or whatever) layer over the top and end up with a bunch of navigation properties that are never (or rarely) used. These tend to either cause unintended lazy-loading or end up as null-reference exceptions.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment13http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment13Wed, 27 Feb 2013 03:31:53 GMT@phil - Because to be in any way reliable this requires temporal data. Otherwise you have two pieces of related data at some point in time that will certainly conflict with one another. An example of this would be when a product's price changes. A customer comes back to dispute a price, the order says it was $500, the product says $450. The system has no record whether the product price was updated, let alone whether it was updated before or after the order was received. Real world scenarios will be more complicated, but keeping that product reference is only practically useful if the data supports a full append-only timestamp model. If it isn't crucially important to have that, then YAGNI.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment12http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment12Wed, 27 Feb 2013 03:06:35 GMTSnapshotting the relevant data is perfectly fine but it does not have to mean that the association should be discarded. Why not maintain both the association and the relevant snapshot? The association connects this entity to other entities in the system and thus permits analysis, which wasn't initially conceived, to be bolted onto the system later and applied retrospectively. Discarding the association seems to be taking YAGNI one step too far. http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment11http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment11Tue, 26 Feb 2013 23:32:08 GMT@Rafal +1 having no option of adding or not an FK it's not a feature. It's implementation/design decision which one have to live with. I'm not saying it's needed for document database like Raven. I'm saying that not having it is not a plus for the db.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment10http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment10Tue, 26 Feb 2013 20:40:10 GMT+1 David. I was going to make the same comment. Whether it is a NoSQL or SQL database OrderLines must shield itself from changes to the Products by at least keeping the name and unit price at time of order.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment9http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment9Tue, 26 Feb 2013 19:13:22 GMTI think what Oren glossed over, and is critical in understanding this concept if you're coming from the RDBMS, is that when we model Order and OrderLines in a document database, we note the ProductID but we also bring in a few critical pieces of the Product as well - maybe just the name. That way, when the product gets deleted later, it doesn't matter. We have all the information we need to display the details of that order I made 2 years ago. The real kicker is that in a relational model, if i bought a Widget 2 years ago, and then 1 year ago the Widget product got updated to become a Super Widget, my order history would now indicate that I bought a Super Widget! But I didn't! I only bought a Widget! By bringing the product name into the Order + OrderLines model, we maintain that historical accuracy no matter what happens to the product at some later date, PLUS we don't have to always remember to select where IsDeleted = 0.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment8http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment8Tue, 26 Feb 2013 17:10:02 GMTIt's less common to see in an app database, but in the Data Warehouse world this is dealt with using "slowly changing dimensions." http://en.m.wikipedia.org/wiki/Slowly_changing_dimension#section_7 (Usually the "Type 2" kind.)http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment7http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment7Tue, 26 Feb 2013 12:51:12 GMTI think we have in the past used foreign keys thinking something like "Hey, now we don't have to think about this relationship in the domain". But despite our efforts to hide aspects of the domain from our minds, it comes back to haunt us. Foreign keys aren't a silver bullet and do end up causing much pain. The number of times I have seen "IsDeleted" and the pain that has also caused is astounding. I think Oren is saying exactly this: we cannot hide these relationships magically from the domain. We must face them head on in our app and deal with them from a business perspective. http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment6http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment6Tue, 26 Feb 2013 12:17:46 GMT@alastair - nullable fk's are evil and will just lead to confusion in the relational db world and cascade deletes cause pain. I think what Oren is trying to say is you cannot approach document db's the same way you approach relational. The things we have to do to keep relational databases happy do not exists when you look at the NOSQL paradigm.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment5http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment5Tue, 26 Feb 2013 11:28:16 GMTMango I don't follow the questionhttp://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment4http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment4Tue, 26 Feb 2013 11:27:17 GMTAyende, ...i'm new to raven ...wath's about the costo of separate aggregates life cycles? tyhanks http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment3http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment3Tue, 26 Feb 2013 11:14:29 GMTMany RDBMS will allow you to specify DELETE behaviour such that deleting the parent record will automatically set the childs key to NULL in this situation.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment2http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment2Tue, 26 Feb 2013 10:41:23 GMTAre you saing that not having inter-document consistency checks in the DB is an advantage over having them? I beg to differ.http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment1http://ayende.com/161153/ravendb-and-not-having-foreign-keys#comment1Tue, 26 Feb 2013 10:36:15 GMT