Before I go off on one of these ideas, I'd like to describe the problem of mapping objects to the database as I see it.
Databases contain tables with columns. These are 2 dimensional structures. Objects contain fields which can be other objects. These can be 2, 3 or even N-dimensional structures. Going from N-dimensions to 2-dimensions requires some sort of mapping. Additionally, in order to represent the N-dimensions in the 2-dimensional structure, it requires multiple tables that are joined together.
As features are added to a product or system, new fields and objects are added which result in additional columns or entirely new tables.
At the "leaf-level" of the problem, the data types in the database do not always line up with the data types in the objects. For example, should a "string" in the object space be mapped to an "nchar" or "varchar" or some other type of "char" in the database ... and then of what size? Likewise, is the granularity of the "DateTime" value in the object space the same as that in the database? If not (and in the cases I've seen, it is not), what can be done to over come that problem? Or is the lower granularity good enough?
Should the table have an auto-incrementing id? Or should some field or combination of fields be used as the unique identifier for a table?
Should inherited objects be stored in a single table? Or should the base class information be stored in one table while the derived object's information is stored in other?
Should an entire set of data be read in? Or should just the top-level object be read in on the initial read with the other levels read in on an as-needed basis? Should this be a configurable option? Should this be an option that changes depending on the size of the data set?
Can the object be serialized and de-serialized instead of being mapped to a table?
No comments:
Post a Comment