﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>interracial lesbians sex commented on Complex EDM</title><description> - 
</description><link>http://ayende.com/2097/complex-edm#comment7</link><guid>http://ayende.com/2097/complex-edm#comment7</guid><pubDate>Mon, 12 Mar 2007 10:50:45 GMT</pubDate></item><item><title>Paul Gielens commented on Complex EDM</title><description>Database normalization applied to the data structures, since the database outlives the applications build around them, increases the gap between the logical and the conceptual model. I hardly come accross 1:1 mappings in the enterprise field these days. The principle “an essential element of good object model design that the object model be at least as granular as the relational model” is an interesting one to discover further.
</description><link>http://ayende.com/2097/complex-edm#comment6</link><guid>http://ayende.com/2097/complex-edm#comment6</guid><pubDate>Mon, 12 Feb 2007 08:56:53 GMT</pubDate></item><item><title>Harald commented on Complex EDM</title><description>A prominent example that comes to my mind I had problems with in the past was a table storing the EXIF info of an image in a metadata table. It is absolutely unlikely that the EXIF info will actually be &gt;8k, but it theoretically could if you add up all maximum field sizes and your only option is to randomly splice it.
</description><link>http://ayende.com/2097/complex-edm#comment5</link><guid>http://ayende.com/2097/complex-edm#comment5</guid><pubDate>Mon, 12 Feb 2007 07:58:34 GMT</pubDate></item><item><title>Anders Nor&amp;#229;s commented on Complex EDM</title><description>[EDM: I'm not impressed either"](http://andersnoras.com/blogs/anoras/archive/2007/02/11/edm-i-m-not-impressed-either.aspx)</description><link>http://ayende.com/2097/complex-edm#comment4</link><guid>http://ayende.com/2097/complex-edm#comment4</guid><pubDate>Mon, 12 Feb 2007 06:36:35 GMT</pubDate></item><item><title>Alex James commented on Complex EDM</title><description>Data often outlives the application that created it, this means that often the justification for a particular data design may no longer exist. And with it this mistaken assertion that you should objects at least as granular as the database. 
  
  
If you are using / creating data in a way that doesn't need that granularity why expose it?
</description><link>http://ayende.com/2097/complex-edm#comment3</link><guid>http://ayende.com/2097/complex-edm#comment3</guid><pubDate>Mon, 12 Feb 2007 03:24:33 GMT</pubDate></item><item><title>Ayende Rahien commented on Complex EDM</title><description>That is a valid point, but even them, just randomly splicing the table is a bad practice, you need to give some though about how you can do that. I would also argue that if your rows are so big, you probably not going to want to load them all at once, but to partition them again for the business layer.
</description><link>http://ayende.com/2097/complex-edm#comment2</link><guid>http://ayende.com/2097/complex-edm#comment2</guid><pubDate>Sun, 11 Feb 2007 19:34:14 GMT</pubDate></item><item><title>Harald commented on Complex EDM</title><description>You somtimes might want (or actually be forced) to do vertical partitioning when you exceed the maximum possible rowsize (which e.g. is about 8k afaik on sqlserver 2k) of the database. This would be an example where you most likely don't want the table-split slip into your object model as the &amp;amp;quot;conceptual justification&amp;amp;quot; is actually a workaround for a limitation of the dbms, and workarounds should always be as encapsulated as possible.
</description><link>http://ayende.com/2097/complex-edm#comment1</link><guid>http://ayende.com/2097/complex-edm#comment1</guid><pubDate>Sun, 11 Feb 2007 09:54:27 GMT</pubDate></item></channel></rss>