Comments on: use YML for storing data in db http://www.symfonylab.com/use-yml-for-storing-data-in-db/ Everything you wanted to know about Symfony framework but did not know who to ask! Fri, 27 Aug 2010 17:19:40 -0700 http://wordpress.org/?v=2.9.2 hourly 1 By: rpsblog.com » A week of symfony #82 (21->27 july 2008) http://www.symfonylab.com/use-yml-for-storing-data-in-db/comment-page-1/#comment-417 rpsblog.com » A week of symfony #82 (21->27 july 2008) Thu, 31 Jul 2008 23:22:27 +0000 http://www.symfonylab.com/use-yml-for-storing-data-in-db/#comment-417 [...] use YML for storing data in db [...] [...] use YML for storing data in db [...]

]]> By: Paul A Houle http://www.symfonylab.com/use-yml-for-storing-data-in-db/comment-page-1/#comment-408 Paul A Houle Tue, 22 Jul 2008 15:47:20 +0000 http://www.symfonylab.com/use-yml-for-storing-data-in-db/#comment-408 I sometimes put a blob in a table. This can be a quick way to store hierarchical data, or other things that don't fit into the SQL model. I've often used PHP serialization or JSON for this purpose. A big problem with using blobs like this is that you lose the intelligence of the database. At some point you might need to do a query on one of the fields hidden in the blob. You could do this in one line of SQL if this was in it's own column, but instead you have to write a program and do a full table scan. Another problem with blobs is evolvability. It's a pain to evolve your schemas in SQL, but SQL provides you the tools to do it. You may be able to cope if your data structures are loosely coupled, but the evolvability problem for OO databases is tough and unsolved. A less drastic model is to create a table that lets you attach key/value pairs to rows in a table. You can still do ad-hoc SQL queries. This doesn't work well for complex structured data, but is a good compromise in many cases. I sometimes put a blob in a table. This can be a quick way to store hierarchical data, or other things that don’t fit into the SQL model.

I’ve often used PHP serialization or JSON for this purpose.

A big problem with using blobs like this is that you lose the intelligence of the database. At some point you might need to do a query on one of the fields hidden in the blob. You could do this in one line of SQL if this was in it’s own column, but instead you have to write a program and do a full table scan.

Another problem with blobs is evolvability. It’s a pain to evolve your schemas in SQL, but SQL provides you the tools to do it. You may be able to cope if your data structures are loosely coupled, but the evolvability problem for OO databases is tough and unsolved.

A less drastic model is to create a table that lets you attach key/value pairs to rows in a table. You can still do ad-hoc SQL queries. This doesn’t work well for complex structured data, but is a good compromise in many cases.

]]>