Timeline for Addressing the fact that primary keys are not part of your business domain
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 28, 2014 at 9:08 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 41 characters in body
|
| Aug 28, 2014 at 6:12 | comment | added | Doc Brown | @corsiKa: in the context of what the OP asked, I would strongly recommend to have a purely autogenerated key "OrderID" (which is not printed on any receipt, but just used for internal things like database references), and a separate business key "OrderNumber" (which can, for example, contain something like the current year, which can be used for sorting and filtering, which can be changed/corrected afterwards, and which can be printed on receipts). OP asked for "Domain Driven Design", the "OrderNumber" is part of the domain model, whilst the "OrderID" is just an implementation detail. | |
| Aug 28, 2014 at 4:14 | comment | added | InformedA |
@corsiKa He suggested right there in the answer, you use surrogate key. He is not saying printing OrderID value in the record is bad. He said, you shouldn't use it as primary key in your table. And many people have already pointed out, this kind of primary key will change in the future, your system will pay dearly for this kind of design. There will be lot of problems all over the places. There are a lot of examples of massive systemic failure because of this kind of thinking and design
|
|
| Aug 28, 2014 at 3:07 | vote | accept | tacos_tacos_tacos | ||
| Aug 27, 2014 at 21:28 | comment | added | corsiKa |
So when you say no business meaning... let's say you have the Order table. When I print a receipt, are you saying if that OrderID value is printed on that record that it's bad? If it's bad, what would you recommend?
|
|
| Aug 27, 2014 at 19:19 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 43 characters in body
|
| Aug 27, 2014 at 18:46 | comment | added | Casey | Natural keys sometimes seem really compelling but it's too easy to get burned (e.g., "whoops, now I have multiple tenants and that's no longer unique"). | |
| Aug 27, 2014 at 14:32 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 1 character in body
|
| Aug 27, 2014 at 14:26 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 53 characters in body
|
| Aug 27, 2014 at 13:47 | comment | added | Doc Brown | @tacos_tacos_tacos: a surrogate key that involves domain data? A surrogate key does never contain domain data by definition, and I think I clearly suggested this usage in my answer . So what are we discussing here? | |
| Aug 27, 2014 at 12:45 | comment | added | tacos_tacos_tacos | @user61852 no, more because in my thinking, if you're going to define a surrogate key that involves domain data, you might as well use the primary key. I mean, it does offer one advantage - it doesn't expose the persistence layer as much, and therefore could be used across multiple persistence layers... | |
| Aug 27, 2014 at 12:00 | comment | added | Tulains Córdova | All this because surrogate keys are ugly ? | |
| Aug 27, 2014 at 11:58 | comment | added | Doc Brown | ... and if performance seems to become a real, measurable problem, you can also consider to cache the mapping (name,url) to VoIPProviderID somewhere. But I would not recommend of implement such an optimization beforehand, prematurely. | |
| Aug 27, 2014 at 11:56 | comment | added | Doc Brown | @tacos_tacos_tacos: let's stick to your VoIPProvider example. I would actually add a "VoIPProviderID" to your DTO, at least at the "implementation side" (if you have also a graphical version for your domain experts, I would probably not show it there). For updating purposes, the standard way of identifying a specific VoIPProvider should be by the "VoIPProviderID" you retrieved when pulling tha data from the database. If users of your API prefer identification by (name,URL), provide that additionally. ... | |
| Aug 27, 2014 at 11:27 | comment | added | tacos_tacos_tacos | What about the step of taking the domain object from the returned persistence object (entity, or table row model, or whatever), going to DTO, and taking it back in, and going back to persistence? Is this just done via a surrogate key (ie a business-oriented definition of uniqueness) that requires a resolution on each persistence operation? | |
| Aug 27, 2014 at 11:04 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 173 characters in body
|
| Aug 27, 2014 at 10:04 | history | answered | Doc Brown | CC BY-SA 3.0 |