Re: Lucid statement of the MV vs RM position?

David Cressey wrote:
> "Pickie" <keith.johnson_at_datacom.co.nz> wrote in message
> news:1146013144.631672.77130_at_j33g2000cwa.googlegroups.com...
>
> > It is possible to build different applications which use the same data
> > files. This is not usually done by independant teams if the data is to
> > be modified.
>
> This is where I diverge from the Pick culture. It's precisely this
> situation that interests me: Independent teams writing applications that
> collaborate by exchanging data in a meaningful, formal fashion.

I have possibly worked with larger system than Pickie has. Applications using the database in one s/w company had the requirement (enforced primarily through code reviews) of using the centrally maintained CRUD services, which took care of some of what a SQL DBMS person would care about (e.g. RI), but definitely not everything.

> If the data is exchanged interactively, you can use a network. If the data
> is to be persistent, and trustworthy over time, you can use a database.
> In either case you want to manage the resource that enables data sharing,
> and the data to be shared.
>
> This divergence of culture explains more about the ongoing debates than
> divergences in the internals of the tool sets, divergences in syntax and
> semantics, and divergences in methodologies, IMO.

Results will vary. Small shops typically have fewer automated standards in place.

> Perhaps by understanding that we are trying to solve different problems, we
> will understand that different things look "good" or "productive" to us.

I will grant that the issues and priorities addressed by SQL DBMS tools and Pick, Cache' or other tools, are different. However, the very same business problems (accounts receivable, manufacturing, student registration, call center operations...) can be addressed for small to large organizations with either approach. MV providers often market now as "embedded" but are often employed as an enterprise database.

I also have not seen more junk data in software that works with MV solutions than elsewhere, but I have seen different kinds of junk data -- character data in numeric fields in an MV system, for example, due to a bug that was fixed without, apparently, repairing all data. On the other hand, you don't have users encoding data in comment fields because the cost of them asking for a change, not to mention the cost of the change, is too high. There are pros and cons to each approach, so it make sense to ask what gives an organization the best results over time for the least amount of dollars. Cheers! --dawn Received on Wed Apr 26 2006 - 22:31:59 CEST