Head in the Cloud

Microsoft SQL Server, as of version 9.0 (2005), allows you to cheat the max row size limit of 8K. If we have a row of variable length data types (ie. varchar), the total byte count can be more than 8K. SQL Server will magically spill the data over to the next page. Cool right? Well... yes and no. Cool if your hands are tied and it gets you out of a jam. Not cool if you care about database performance and scalability. Having a row span more than one page (in Oracle we call them blocks), results in page (or block) chaining. The overhead involved in block chaining can cause some significant performance hits depending on how often it happens, size of the table, fragmentation, etc. This goes for most any popular RDBMS. Let's look at Oracle (no point in just picking on SQL Server). Oracle allows a 64K max row size (and that's a hard limit... no loosy goosy there). However, block size is determined by the value of the db_block_size init parameter set during database cre

I was approached by a developer suggesting a reflection routine for taking values from a data transfer object and populating a business entity and vice versa. He argued that writing a TransferObjectAssembler for each DTO was too time consuming, and would be better suited with a reflection routine. My response was no, not a good practice. But why? It seemed clean enough. It was fairly straight forward code for the particular implementation scenario he was looking at. So, why not? It would certainly save a few million lines of code. But what are we really saving? And at what cost? It's no secret--reflection is slooooowwwww. At least in comparison to explicit design-time coding. Case in point: I helped out with a code review of a similar implementation where reflection was being used to create a generic routine to "convert" DTOs to business entities and vice-versa. While the DTOs were quite large, they were not ridiculously complex, and very typical of the particul