Relational database reinvented as a flat file...
-
Just remembered another stunning design stumble in the same area as the multiple database scenario ... they had a SQL table and decided that because the majority of requests required the output in XML format, it would be "best practice" (that weasel word again) to convert the entire table into a blob of XML. They then dropped the original table and recreated it as a table with 1 row and 1 column, into which they inserted the XML blob. Unfortunately they had not realised that most requests wanted a subset of the table, not the entire table. So for each request, the XML blob had to be converted to a temp table, the appropriate SELECT run on it, and the results sent back to the requester as XML ... Phew!! Inserts, updates and deletes had to go through the same process: XML blob -> temp table -> apply insert/update/delete -> convert back to XML blob, save back in the "table".
-
Just remembered another stunning design stumble in the same area as the multiple database scenario ... they had a SQL table and decided that because the majority of requests required the output in XML format, it would be "best practice" (that weasel word again) to convert the entire table into a blob of XML. They then dropped the original table and recreated it as a table with 1 row and 1 column, into which they inserted the XML blob. Unfortunately they had not realised that most requests wanted a subset of the table, not the entire table. So for each request, the XML blob had to be converted to a temp table, the appropriate SELECT run on it, and the results sent back to the requester as XML ... Phew!! Inserts, updates and deletes had to go through the same process: XML blob -> temp table -> apply insert/update/delete -> convert back to XML blob, save back in the "table".
-
Just remembered another stunning design stumble in the same area as the multiple database scenario ... they had a SQL table and decided that because the majority of requests required the output in XML format, it would be "best practice" (that weasel word again) to convert the entire table into a blob of XML. They then dropped the original table and recreated it as a table with 1 row and 1 column, into which they inserted the XML blob. Unfortunately they had not realised that most requests wanted a subset of the table, not the entire table. So for each request, the XML blob had to be converted to a temp table, the appropriate SELECT run on it, and the results sent back to the requester as XML ... Phew!! Inserts, updates and deletes had to go through the same process: XML blob -> temp table -> apply insert/update/delete -> convert back to XML blob, save back in the "table".
-
:wtf:
Software Kinetics - Dependable Software news
-
Just remembered another stunning design stumble in the same area as the multiple database scenario ... they had a SQL table and decided that because the majority of requests required the output in XML format, it would be "best practice" (that weasel word again) to convert the entire table into a blob of XML. They then dropped the original table and recreated it as a table with 1 row and 1 column, into which they inserted the XML blob. Unfortunately they had not realised that most requests wanted a subset of the table, not the entire table. So for each request, the XML blob had to be converted to a temp table, the appropriate SELECT run on it, and the results sent back to the requester as XML ... Phew!! Inserts, updates and deletes had to go through the same process: XML blob -> temp table -> apply insert/update/delete -> convert back to XML blob, save back in the "table".
johnsyd wrote:
Inserts, updates and deletes had to go through the same process: XML blob -> temp table -> apply insert/update/delete -> convert back to XML blob, save back in the "table".
Presumably without any locking to ensure that concurrent changes don't get lost? X|
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Just remembered another stunning design stumble in the same area as the multiple database scenario ... they had a SQL table and decided that because the majority of requests required the output in XML format, it would be "best practice" (that weasel word again) to convert the entire table into a blob of XML. They then dropped the original table and recreated it as a table with 1 row and 1 column, into which they inserted the XML blob. Unfortunately they had not realised that most requests wanted a subset of the table, not the entire table. So for each request, the XML blob had to be converted to a temp table, the appropriate SELECT run on it, and the results sent back to the requester as XML ... Phew!! Inserts, updates and deletes had to go through the same process: XML blob -> temp table -> apply insert/update/delete -> convert back to XML blob, save back in the "table".
