Hi Elliot,
welcome to Isis

On 28 February 2013 01:22, Elliot Finley <[email protected]> wrote:

> Hi all,
>
> If I have a client with a large legacy SQL database, or if they insist on
> designing the database before writing any code - is it feasible to use Isis
> on top of that?
>

Probably.

That is: you can probably use views to provide a logical projection away
from your legacy schema.   In most RDBMS views are read-write rather than
read-only; if the view is simple enough then it inserts, updates and
deletes can be made through the view with no further coding; if the view is
more complex then an INSTEAD OF trigger can be used.  A quick google
indicates that this is supported by SQL Server, Sybase, Oracle, DB2, and
Postgres.   It does *not* appear to be available in MySQL.

I would argue that even if the database schema is not legacy, there's still
an argument for always accessing it through views.  The views represent
what I once would have called the logical data model, whereas the tables
are the physical data model.  Over time there are likely to be other
clients of the data than just the online webapp - you might have a batch
process, or a reporting tool, or some bespoke apps, or who knows what.  If
each of these clients access the data through their own set of views then
you make it much easier to do impact analysis if the physical schema needs
changing (eg denormalized to support such-and-such a requirement).  The
views are an abstraction that give you the "get out of jail" card.

As a bonus, you can also use them for security.  By preventing direct
access to the tables, it stops someone knocking up some adhoc but important
(eg for the CEO) reporting tool which then breaks later on because you
weren't aware of it.

If working with a legacy database, what I would do is to pretend you are
greenfield and let Isis build its database tables in an empty dev database,
and then write the views in the legacy database that match the schema of
the generated tables.  You could probably then write a tool to check the
structure, and put it in your CI to flag if your view definitions have
become out of date.  During development, I'd carry on working in my
greenfield database, but use the views in the legacy database to copy
representative data over.  Later on as you move into system testing and
your logical schema has stabilised, you can ditch the greenfield database
and point Isis to your views.

One last point: most databases - again SQL Server, Sybase, Oracle, DB2,
Postgres - support materialized views.  This can be handy if your app is
mostly read-only rather than read-write, and don't want the performance hit
of deriving data through a regular view on every query.

Hope that helps
Dan



>
> Thanks in advance,
> Elliot
>

Reply via email to