Re: In an RDBMS, what does "Data" mean?
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 08 Jun 2004 02:05:50 +0200
Message-ID: <40c502d8$0$6968$e4fe514c_at_news.xs4all.nl>
>
> Except that Dawn's experience (and most MV consultants, too) is that the
> cost of maintaining old MV databases is lower than that of maintaining
> relational ...
>
> They're cheaper to write, they're cheaper to maintain, and they take a
> LOT longer to get decrepit ...
Date: Tue, 08 Jun 2004 02:05:50 +0200
Message-ID: <40c502d8$0$6968$e4fe514c_at_news.xs4all.nl>
> mAsterdam writes
>
>>> By focussing on minimising the complexity of one part of the system, >>> we make the system as a whole more complex. That will explain why >>> Dawn's experience is that MV is more productive than relational - >>> the simplicity of the relational database over MV simply pushes all >>> the complexity into the business analysis side, turning that into a >>> total nightmare. >> >> >> I'll state my intuition (not backed up by experience) >> about not taking the time to analyse data: >> postponing the basic issues will bring volatile >> quick wins, pushing depth investment (cost) of >> reflection and the real benefits of data assests >> into the future. So, if and only if your survival >> depends on quick wins, go for it.
>
> Except that Dawn's experience (and most MV consultants, too) is that the
> cost of maintaining old MV databases is lower than that of maintaining
> relational ...
>
> They're cheaper to write, they're cheaper to maintain, and they take a
> LOT longer to get decrepit ...
As I understood your writings you claim to analyse your data before taking a well-informed decision to prefer MV implementation above a RDBMS implementation. How can my statement about quick wins trigger this response? Received on Tue Jun 08 2004 - 02:05:50 CEST