Re: Please Help
- From: dawn <dawnwolthuis@xxxxxxxxx>
- Date: Thu, 12 Jun 2008 18:52:20 -0700 (PDT)
On Jun 12, 6:14 pm, Tony Gravagno
<address.is.in.po...@xxxxxxxxxxxxxxxxxxxxxx> wrote:
(Originally written several days ago, somehow didn't go out)
Tony wrote:
...The multi-value Pick database model is not relational...
Jim Responded:
So, for "LA's" purpose, and for mine as well - Is PICK/MV "relational"
or not? Or is this like "BEAUTY" - it's in the eyes of the beholder?
Hi Jim. The rest of my quote was "... and doesn't require the
developer to have a grasp of database theory. ... The bane of this is
that MV people are generally not technical...".
In that context one key but non-academic factor that separates MV from
relational is that hardcore "educated" relational people tend to
approach tasks according to what's right in terms of the rules of
relational data processing, while Pick people tend to do whatever
works to get the job done. At a real fundamental level this sort of
pragmatism is part of what keeps us together and so passionate about
the model.
But that's not really what you're asking. Being a pragmatist of
sorts, and not a trained DBA, I'm not qualified to detail too many of
the theory-oriented aspects of Pick vs Relational.
This one area where I'm willing to say that I have a little bit of
expertise, I think, maybe (they say women rarely suggest expertise in
anything, but if they do they are likely to lose the primary ;-).
I just noticed that there have now been more than 15,000 unique
visitors (per google analytics) to the Is Codd Dead blog entry. That
isn't much compared to blogs that advertise and play the blogosphere
games, but given that I set a goal of having 100 people read my blog,
given its very narrow focus, I'm really quite blown away. There are a
few unposted entries I should get out there, but the 2006 series as it
stands, starting with the following first entry, gives some of my
perspective on this topic. This entry alone was designed to state
simply and clearly the difference of opinion and perspective from that
of many who learned relational theory in college or have practiced
data modeling with Oracle, My SQL, SQL Server, etc.
http://tincat-group.com/mewsings/2006/01/is-codd-dead.html
(Yup, here's one
example that proves the point I was trying to make up there. ;) )
But here are a couple key points and I'm sure others with a clue can
add more.
- A key differentiator between _MultiValue_ and relational databases
is that we put multiple values in a given field and they create
relations between a primary table and secondary tables which contain
multiple values for a given field. This is slowly changing as the
rest of the world is coming to know a new word: "multidimensional".
- The relational data model is much more tightly bound to the
Structured Query Language than the Pick model is tied to its own query
processors.
Yes, SQL is prescriptive, while all Pick metadata is merely
descriptive. This is very difficult for those who have done a lot of
SQL to even comprehend. Just the ability to have synonyms for an
attribute seems like an impossible feat to some, not to mention the
variable length fields.
- Relational database schemas are very type-sensitive. MV can be, but
for better or worse it's not mandatory.
The relational model and RDBMS products incorporate strong typing,
where MV is much more like JavaScript in its loose or duck typing.
We're given the freedom to
make the best of it or to hang ourselves - and from time to time we've
all done both.
Pickies get enough rope to hang themselves in different ways than
RDBMS developers hang themselves. Each has problems with schema
change, data integrity, and data quality, but the issues tend to be
different for each.
- An RDBMS has built-in protections for referential integrity (RI)
which are defined into the data tables and their relations. An
update-type query cannot violate the RI defined in the database. RI
in MV is maintained by code.
Although using Cache and MV, I am using some of the RI features built
in because there are some side-effect benefits (use of . I might be
sorry at some point, but so far, so good. In other products, such RI
is often built into higher level tools built by a VAR or a site, so
even when it is "maintained by code" it might very well be in tools
and libraries used to write the app software.
This isn't inferior, no more or less
fallable. We've simply chosen to put rules in BASIC modules rather
than in the table definitions. It's sort of like RDBMS triggers are
universally supported right above the data layer, so they are
respected no matter how you update the database. I really wish MV
platforms universally provided that sort of robust handling, but
triggers in MV have always been treated as an after-thought.
BTW, triggers are not typically valued by relational purists either.
They prefer constraints specified to the DBMS.
- Similarly, Pick people approach the database from programs. The
BASIC program is our universal input/output interface and includes our
RI. The RI is maintained by the application developer, not by the
DataBase Administrator. This is a fundamental shift of
responsibility.
There is often not such a thing as a DBA in the Pick world and when we
do give that title to someone, the job function is different from that
of an RDBMS DBA. There is definitely no problem of DBA vs other
Developers (e.g. coders) in any antagonistic relationship or any
policing from the DBA crowd or "try to work around the DBA rules" from
the programmers. The culture of a typical Pick shop is the one "agile
developers" are aiming for.
cheers. --dawn
<snip>
.
- References:
- Re: Please Help
- From: JJCSR
- Re: Please Help
- From: Tony Gravagno
- Re: Please Help
- Prev by Date: Re: Please Help
- Next by Date: Re: [AD] OpenQM on Intel Mac
- Previous by thread: Re: Please Help
- Next by thread: Re: Please Help
- Index(es):
Relevant Pages
|
