> if there's no way to enforce strict schemas you end up with a lot of headaches. I think the idea here is that your database schema is isomorphic to the rest

> if there's no way to enforce strict schemas you end up with a lot of headaches. I think the idea here is that your database schema is isomorphic to the restrictions on your in-memory data enforced by your application code: you can't store objects that you can't create in the first place, so that's your schema. Of course systems like AllegroCache blur the difference between in-memory and stored data completely. > another problematic things I saw: period 20xx/xx/xx to 20yy/yy/yy the informal schema was A, then it was changed to B, then after that to C. of course old data was not migrated to the new design each time, giving that the system work mostly in an online fashion that was not much of problem. expect the requirements changed or you found out something it not right and you need to recacultate a result that depdent of the date from the beggining up to now. now querying this data is a nightmare. For example in AllegroCache this would be solved by usual object migrations (like in http://clhs.lisp.se/Body/f_upda_1.htm http://clhs.lisp.se/Body/f_upda_1.htm), perhaps even lazily as to not disrupt operation.