Re: 3vl 2vl and NULL
Date: Fri, 17 Feb 2006 12:45:12 GMT
Message-ID: <szjJf.10307$yK1.7167_at_news-server.bigpond.net.au>
dawn wrote:
> Frank Hamersley wrote:
>>dawn wrote: >>>Frank Hamersley wrote: >>>>dawn wrote:
> <snip>
>>>>For my benefit can you identify the top 5 (in your opinion)? >>> >>>1) The query language has no corresponding update language ever put >>>into production >> >>Was there a plan to do so, or was PickBasic deemed capable enough?
>
> Chandru (who has posted in this forum) wrote an update processor in the
> early 70's that wasn't quite ready for prime time when Pick joined
> forces with Microdata, so that software was not bundled with the
> system. I don't know the whole story, but it appears that the project
> was picked up in the 80's and was a pet project for Dick Pick. There
> are interactive tools, but no language-based set processing update
> processors that I have found in my look over the MV landscape. I would
> guess that one reason this was never completed or implemented was that
> DataBASIC is a very full-featured language that satisfied the primary
> requirements for developers, so there was no outcry (and still isn't).
Fair enough - maybe one day, maybe not!
>>So >>every update is a programme? Thats not so bad if you have a "copy deck" >>of standard templates and access/update methods.
>
> Yes. Often CRUD services are written (SOAs are not a new concept ;-).
>
>>Of course with SQL >>large portions of the query statement can be used in forming the update.
>
> Similarly, the query language can be used to get what is called a
> select list or saved list of keys for the selection aspect of what to
> udpate.
>>>2) The DataBASIC language often used in MV solutions
> <snip>
>>So is C :-). What sort of library support does it offer?
>
> I'm not a DataBASIC programmer, so maybe someone else will pick this
> up.
> <snip>
>>How do you predict all of the required logical views for ad hoc queries
>
> That is a significant issue. Most sites don't predict, but react to
> requests throughout the development process and after an application is
> live, adding in virtual fields (derived data or path to attributes in
> other files) as needed. At one site I worked, we hired student
> employees to work a few hours a week to add virtual fields as requested
> and if any report was too complex for end-users, then they would write
> the report for them too.
> During all those years of companies working hard to get end-user
> reporting, MV end-users were either churning out reports and ad hoc
> queries or asking their VARs or IT shops for new ones and getting a
> fast turn-around on their requests.
>
> [Anecdote: I moved from an IMS COBOL shop with a significant backlog
> for reports to an MV shop with no backlog, zero, zip, for any
> reporting. It was very enlightening.]
No doubt - COBOL would not be my lang of choice however!
>>- is this an important additional phase in the design phase or is it >>simple to retrofit on demand?
>
> simple, but not something you typically pass to an end-user to do since
> it adjusts the schema (which is descriptive and not prescriptive, so
> the risk is to other queries).
What happens to these view if cardinality is changed - perhaps even arbitrarily - are they "self healing" or do they require maintenance?
>>>4) There is no standard across vendors for a data source definition. >>>There is no standard for client-server connectivity. This gives third >>>parties the floor to write products like the jBASE mv.NET product that >>>works with many different flavors of MV. >> >>So each programme instance latches on to the files directly - no daemon >>request-response mechanism possible?
>
> Each vendor has their own daemon approach for client-server, but these
> are not standardized. VARs and 3rd parties do not write
> MV-database-independent applications as often as they do in the SQL
> world.
Does it get deployed in multi-tier apps much - the one I saw was single tier.
>>>5) Third-party products for Business Intelligence and practically >>>everything else speak ODBC
>
> <snip>
>
>>Is it easy to dump (aka bcp out) to another (SQL?) environment for ad >>hoc queries, routine reporting or data warehousing?
>
> A techie would say that it is easy and I have advised and assisted in
> such efforts many times, but find it not altogether satisfying. Once
> you normalize the data, your solution is no better than the average SQL
> implementation so you lose the charm (e.g. ease in working with
> multiple 1:M's in queries) and have the added pain of such things as
> switching from 2VL to 3VL, for example (equating a Pick null with a SQL
> null does not typically work well). Those for whom I have recommended
> this approach for their specific requirements have told me it is
> working well for them, however.
Is there no other way to leverage these BI products?
>>>I'm not sure these are my top 5, but they are 5 of the top issues I >>>have with MV. >> >>Ouch - in my current business space, any of those would hurt like >>amputation without anaesthetic!
>
> Yup, there are pros and cons with SQL products and with non-SQL
> products. In spite of these issues and others, MV typically still
> seems to be a bigger bang for the buck solution for companies. Just as
> people defend the RM while having problems with SQL, I think the MV
> data model has a simple elegance and something like it could help the
> s/w dev industry reduce costs and improve products in a big way. JSON
> and XML are both "something like it" in different ways but do not carry
> successfully into the persistence layer (yet?), while MV has a
> significant (even if invisible, bz it is sold through VARs) installed
> base.
There are no silver bullets! It reminds me of a prediction that I made
when I first started in IT. I suspect I would need a different job in
about 5 years because at the rate IT was expanding by that time
programme writing programmes would make me as a hacker redundant. Of
course I was coding in ASM at the time and we had been exposed to
Modula-2 plus reviewed the Ada spec in the course, and it seemed like a
formality. Of course I was wrong - so I gave trying to predict and just
look for empirical data - which is why I see the market share as
confirming the RM over the MV. Anything that upsets this apple-cart is
going to be novel, not a throwback - yikes, another prediction!
>
>>>>>When talking about data modeling, however, that is one area >>>>>where I cannot leave MV behind unless I can find a better data model.
>
> <snip>
>
>>Even if your data model ambitions were accepted, I doubt I could cop any >>of your top 5 to get that.
>
> I'm not aiming to convince a current SQL-DBMS customer to adopt an MV
> database, even if they would be well-served. I'm trying to convince
> "the industry" to adopt more flexible (dare I say "agile") data models
> and related tools. That is why I smiled when Oracle bought a non-RDBMS
> product line with Berkeley DB and DB-XML and when IBM bought U2
I wouldn't ascribe too much to moves by marketing types.
> (although they didn't know what they had at first). I don't think you
> can easily transition an RDBMS to where it needs to be (backward
> compatibility issues) so these companies need to start with something
> other than the RM (i.e. ditching the Information Principle) and SQL and
> move forward from there on some front.
Good luck to them - hey why not bet on red and black, since 70 to 80% (anecdotally) of project sinks without much trace why not do a Chaney and spray shot all around!
>>>>OK - but to summarise our discussion to date your problem with the RM is >>>>the inherent constraints prevent you from having a visually aligned data >>>>model that correlates exactly with the user view of the data model as >>>>particularly expressed by the UI. >>>> >>>>Is this a (relatively) succinct statement of your view? >>> >>>I don't think so because I think your defs sound different from mine. >> >>Thats why I restated in just 4 lines - on rereading them and my next >>para is it the nub of your opinion? >> >>>By "correlates exactly with the user view" it sounds like you think I >>>want the data from a single screen to be stored as a single entity or >>>something like that. I would not look for the logical data model of UI >>>screen to be identical to the logical data model of the database. >>>Surely one screen might collect data that updates multiple entities. >> >>I didn't (except for the need of brevity) aim to make it all or nothing, >>more that the alignment is very obvious in the MV situation and can be >>apparently less clear (to some) in the RM form.
>
> I still would not say "visually align" although perhaps you could add
> "and linguistically aligned," so you can tell it is more aligned with a
> person's model of the situation. The UI gives hints on what aligns
> with how humans think as does the data structure of a UI. Data need
> not be stored in a way that works for humans, but the interface between
> the rest of the software (e.g. UI) and the database API as well as the
> human working with the interface to the database can be much better
> than with a language that implements the RM, IMO.
> <snip>
>
>>>>b) CLR >> >>I think the Lazza's O and others have some similar facilities - Sybase >>opts for Java, but Bill is going for the whole sorry .Net kitchen sink! >> >>>Are these both SQL Server only? I don't know what the downside of CLR >>>is. >> >>RISK - like you have with MV (only joking, well not really, but far >>worse). Every half wit who finds regular SQL too taxing will start >>building bits and pieces of smart alec code and then ram it into the >>database -
>
> That is what I figured you were thinking. Coming at it from the s/w
> dev standpoint, I have mixed feelings on that one. I very
> .NET-ignorant (by decision so far), however.
>>that like all M$ stuff will fail from time to time. Argggh - >>all the mayhem you can handle and then more! As a foretaste I have >>already heard of ppl shelling out of sprocs to instantiate an object >>that invokes a DTS package to munge the very data they are interested >>in. So what if you lose a bit on the way.
>
> laughing. Flexibility is one of those features that some folks just
> hate, eh? You then have to hire good developers and have good testing
> (even then I'll grant it isn't air tight).
Yep - in some places it is more dangerous and others it is desirable. Always it must be in good hands.
>>>>This simply confirms what Canute discovered. His goal may be correct >>>>but his method not. That doesn't mean it is unachievable as the Dutch >>>>have showed. >>> >>>Unless you are talking about King Canute and the Dutch holding back the >>>sea? That is the only thing that comes to mind, otherwise I'm clueless >>>on the allusion. >> >>Couldn't be any other conclusion could it? He didn't and they did!
>
> I wasn't sure you wanted me to haul out the liberal arts or if there
> was some techie stuff I was missing ;-)
>
> Cheers! --dawn
Cheers, Frank. Received on Fri Feb 17 2006 - 13:45:12 CET