On Mon, Mar 8, 2010 at 11:12 AM, Aurynn Shaw <[email protected]> wrote:
> The database tables should be likened to private methods and > datastructures of an object - they're hidden, and exposed via an API > interface, which allows for deep refactoring of underlying concepts > without breaking other applications. Handling everything in stored > procedures as opposed to allowing an ORM to manipulate internal > structures achieves a similar abstraction and ability to refactor as > necessary. > > Allowing direct access to the tables, even for SELECT statements, would > force table design to remain relatively static, even if significant > redesign is necessary. In terms of contact management schema stuff, I see the point here. It may take a few modest revisions to get that right. For other areas, I am not so sure as the data storage requirements are unlikely to change. Really, if we want or need to to, we can bring back the typical way this problem is handled, with a division between a logical schema (VIEWS with rules for insert/update/delete as applicable) which are accessible and stable, and a physical, more optimized and/or normalized schema which would be generally inaccessible. (Maybe the contact management should be technically an addon but bundled with the minimal distribution?) Also, long-run, stability would be a net positive because every time we change underlying tables, we will break addons which rely on RI checks etc. If we move towards a more add-on-centric model, it becomes much more important to encourage stability here. > > However, a good place to implement reporting queries would be with a > Report permission level, and several views that provide the required > information. This would allow for a static API that can be queried, and > still permit underlying table modification as needed - A If we have to go that route, I suggest we use VIEWS. The VIEWs could even have insert/update rules to provide backwards compatibility. What they can't do is be targets of RI constraints by addons. For example... Invoices against goods/services will be an addon. It will need to have its tables reference the journal table. If the journal table is suddenly refactored, that will break the addon. On the other hand, if we split location into address, city, and state/province tables, a unified view could allow applications to read/write that data as if nothing changed. Best Wishes, Chris Travers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
