Re: Proposal for 2.0: SODA 2.0

[Chris Travers <..hidden..>]

On Mon, Mar 8, 2010 at 11:12 AM, Aurynn Shaw <..hidden..> 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