What features do we want in a DBMS? 
Author Message
 What features do we want in a DBMS?

Quote:

>I'm hopeful we can use the newsgroup for something constructive for a change.  

No comment.

Quote:
>Rather than "conclude" that .DBF files are the greatest thing since sliced
>bread or that Jasmine will soon rule the world I suggest we look at things
>from the other direction.

Straw men.

Quote:
>What features do we want in a DBMS?  Then we can grade various systems by how
>well they conform to those things we think are important.

Excellent topic for comp.databases.

Clipper, BTW, is not a DBMS.



Mon, 31 Dec 2001 03:00:00 GMT  
 What features do we want in a DBMS?

I'm hopeful we can use the newsgroup for something constructive for a change.  
Rather than "conclude" that .DBF files are the greatest thing since sliced
bread or that Jasmine will soon rule the world I suggest we look at things
from the other direction.

What features do we want in a DBMS?  Then we can grade various systems by how
well they conform to those things we think are important.

I obviously have a few ideas about what the common criteria are but I don't
want to list a bunch of them so let's all add to the list.  If nothing else
you can use the list to make decisions the next time you consider a
change in your development platform.

Also... it's a fine edge but there is a difference between saying "it should
be cheap" and "cost."  Cost is a criteria, "it should be cheap" is an opinion
because "cheap" is relative particularly if "reliability" is your main
concern.

So I'll start with:

Cost
Speed
Scalability
Reliability

Anybody else?

---> Learn a little something at http://www.leylan.com - Now with "Quote for the Day"



Tue, 01 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?


Quote:
>So I'll start with:

>Cost
>Speed
>Scalability
>Reliability

>Anybody else?

Referential Integrity

--

        Oasis WWW  http://www.iag.net/~philb/
         FTP Site  ftp://ftp.iag.net/pub/clipper
      Clipper FAQ  http://www.iag.net/~philb/clipper.html
  Harbour Project  http://www.Harbour-Project.org

      The game will never end. For the game is
        life itself, and life is Who We Are.



Tue, 01 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Quote:

> What features do we want in a DBMS? Then we can grade various systems by
> how well they conform to those things we think are important.

I can see this is tangential to Clipper but isn't this really a discussion
that's better had in one of the DBMS oriented news groups?

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Tue, 01 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?


Quote:


>>So I'll start with:

>>Cost
>>Speed
>>Scalability
>>Reliability

>>Anybody else?

>Referential Integrity

Transaction processing with/rollback

Integrated security

Bi-directional Replication

"It's much easier to develop software using actual technology, instead of just made-up stuff."



Tue, 01 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Quote:




>>Referential Integrity

>Transaction processing with/rollback
>Integrated security
>Bi-directional Replication

Good suggestions from both of you... I can't imagine anybody disagreeing.  
Though "bi-directional replication" is a fairly modern concept and concern.

And actually I think the word "feature" isn't quite right but everybody
understands what I mean... what qualities and characteristics do we deem
important.

Tom

---> Learn a little something at http://www.leylan.com - Now with "Quote for the Day"



Wed, 02 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Quote:


>> What features do we want in a DBMS? Then we can grade various systems by
>> how well they conform to those things we think are important.

>I can see this is tangential to Clipper but isn't this really a discussion
>that's better had in one of the DBMS oriented news groups?

It would be if there was a Clipper subgroup on it.  I really don't care what
people who always use Oracle 8 want in a DBMS... they work on a different
class of problem from what I will call the "normal" Clipper developer.

A recent post mentioned (indirectly) how a simple .DBF has the benefit of not
needing a professionally trained DBA to administrate it.  Some problems just
aren't that important or worth the cost.

And more directly, I think the question is "what is wrong with .DBF files I've
used them for years" the people who ask that question aren't likely to follow
a discussion on comp.databases.

It will be over in a day anyway, it requires thought.

Tom

---> Learn a little something at http://www.leylan.com - Now with "Quote for the Day"



Wed, 02 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?


Quote:





>>>Referential Integrity

>>Transaction processing with/rollback
>>Integrated security
>>Bi-directional Replication

>Good suggestions from both of you... I can't imagine anybody disagreeing.  
>Though "bi-directional replication" is a fairly modern concept and concern.

Sure, but as long as we were building a feature list, I didn't see any
reason to not mention it 8-)

Terry

"It's much easier to develop software using actual technology, instead of just made-up stuff."



Fri, 04 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Tom,

'Compatibility' would rate high on my list.
(Don't break what I got now.  Let ME stage the integration.)

'Ease of use' is critical.
Visual representation (linking) of tables & keys would be required.

'Code generation' would top it off.
Generate the necessary 'SQL' code for me, let me 'cut-n'-paste' back
into the legacy app.

Regards,
Bob


Quote:

> I'm hopeful we can use the newsgroup for something constructive for a
change.
> Rather than "conclude" that .DBF files are the greatest thing since
sliced
> bread or that Jasmine will soon rule the world I suggest we look at
things
> from the other direction.

> What features do we want in a DBMS?  Then we can grade various
systems by how
> well they conform to those things we think are important.

> I obviously have a few ideas about what the common criteria are but I
don't
> want to list a bunch of them so let's all add to the list.  If
nothing else
> you can use the list to make decisions the next time you consider a
> change in your development platform.

> Also... it's a fine edge but there is a difference between saying "it
should
> be cheap" and "cost."  Cost is a criteria, "it should be cheap" is an
opinion
> because "cheap" is relative particularly if "reliability" is your
main
> concern.

> So I'll start with:

> Cost
> Speed
> Scalability
> Reliability

> Anybody else?

> ---> Learn a little something at http://www.leylan.com - Now with
"Quote for the Day"

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


Fri, 04 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Quote:

>'Compatibility' would rate high on my list.
>(Don't break what I got now.  Let ME stage the integration.)

I'm going to wrap the thread up because I started it so poorly.  But let me
ask, compatibility with what?

I tend to think if there was seamless way to get DBMS capabilities built
around .DBF files it would have been done already.  While systems exist,
Advantage Server and Delphi's BDE to name two the majority of the power in
both of these products comes when you stop using standard .DBF files.

You would make the change from record-oriented to set-oriented, you'd
log-on/log-off a server, you'd approach operations from the "transaction"
standpoint.  You wouldn't choose the index to use, the DBMS would.

Basically the code wouldn't resemble Clipper.  And for the pain you get
transaction commit/rollback, security, SQL access, referential integrity,
stored procedures and scalability.

Quote:
>'Ease of use' is critical.
>Visual representation (linking) of tables & keys would be required.

I think there are "ease of use" types and "give me power" types.  I'm not
certain there is an "easy and powerful" solution.  Take for instance
Microsoft's ADO (ActiveX Data Object) model.  Might be considered "not easy"
but it is infinitely flexible.  A TBROWSE on steroids.

I think it is fair to say that a visual representation can be placed atop any
DBMS, it is just a presentation layer that accesses the engine below.  One
can't however place the GUI layer on top of a non-existent DBMS so we'll need
the DBMS first.

Quote:
>'Code generation' would top it off.
>Generate the necessary 'SQL' code for me, let me 'cut-n'-paste' back
>into the legacy app.

Again it is a tool thang!  I'm not certain how it knows what you want but
if you select fields from a list and it generates SQL there will be a dozen
tools for every DBMS currently on the market.

Anyway... I blew it on the title of the thread.  I meant to ask what qualities
are important in making a decision about which DBMS to use.  It sounds close
to the same but I think the differences are subtle enough to lead down another
path.

Thanks,

Tom

---> Learn a little something at http://www.leylan.com
---> Now in French, German, Italian, Portuguese and Spanish



Sat, 05 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?


Greetings Tom,

Quote:
>  But let me ask, compatibility with what?

With the CA-Clipper 5.x RDD system.  In an "ideal" situation, the
interface of the product would not preclude use of a given RDD.
Just keeping 'on-topic' (specific to Clipper) here.

Quote:

> I tend to think if there was seamless way to get DBMS capabilities
built
> around .DBF files it would have been done already.  While systems
exist,
> Advantage Server and Delphi's BDE to name two the majority of the
power in
> both of these products comes when you stop using standard .DBF files.

Agreed.

Advantage DB Server is an excellent example of an interface that
effectively compresses the learning curve, you set up a Server, link in
a replacement RDD, and GO.  It doesn't get much easier to 'stage' an
application from direct 'table' (.Dbf) access to rudimentary C/S.  The
interface doesn't require the developer to adopt a completely new
"methodology" before commencing to 'stage' (up-level) the application.

Of course, the developer has to *enhance* the application if they wish
to take full advantage of additional range of capabilities, this is to
be expected.

Quote:
> You would make the change from record-oriented to set-oriented, you'd
> log-on/log-off a server, you'd approach operations from the
"transaction"
> standpoint.  You wouldn't choose the index to use, the DBMS would.

> Basically the code wouldn't resemble Clipper.  And for the pain you
get
> transaction commit/rollback, security, SQL access, referential
integrity,
> stored procedures and scalability.

Agreed, ultimately the 'underpinnings' of the application would look
significantly different than the same app. using RDD (.Dbf) access,
although (in my limited view) I don't see any reason why the code has
to look VASTLY different.  Hopefully the following will clarify:

RDD Code:

// Order Record update:

SELECT ORDERS
Seek ( nOrdNum )

IF FOUND()
   IF RECLOCK(5)
      REPLACE ... WITH ...
      REPLACE ... WITH ...
      // or ..
      RecUpdate( aOrders_ )  // Scatter-Gather() array..
      COMMIT
      UNLOCK
   ELSE
      Alert("Could not lock record for update at this time.  Retry ?" )
   ENDIF
ELSE
   Alert( "Critical Error!  Order Record no longer exists !" )
ENDIF

// SQL Order Record update:

SELECT ROW FROM COLLECTION oOrders FOR ( oOrders.OrdNum IS_EQUAL_TO
(nOrdNum) )

IF oOrders.NotFound()   // ( oOrders.SelectedRowCount() == 0 )
   Alert( "Critical Error!  Order Record no longer exists !" )
ENDIF

IF oOrders.SelectedRowCount() > 1
   // Handle accordingly: LOG AS ERROR - ROW MERGE/PURGE
ENDIF  // Should only be (1) Row for each (unique) Order..

IF oOrders.CanTransLockRow() // Physical or Deferred (Trans) lock ..
   BEGIN TRANSACTION LABEL "oOrders"
     // Option (A)
     UPDATE ROW USING ARRAY aOrders_    // Scatter-Gather() array ..
     // Option (B)
     UPDATE ROW USING OBJECT oOrders.SelectedRow()  // Collection..
   END TRANSACTION

   // replicate to alternate DBMS else Rollback the Transaction !
   IF TRANSACTION "oOrders" SUCCEEDED // ( oOrders.TransSucceeded )
      COMMIT TRANSACTION "oOrders" TO DATABASE
      STORE TRANSACTION "oOrders" TO LOG
      REPLICATE "oOrders" TO ( Some other DB ) USING LOG
   ELSE
      ROLLBACK TRANSACTION "oOrders"
      Alert( "Order Record update failed! " )
   ENDIF
ELSE
   Alert("Could not lock record for update at this time.  Retry ?" )
ENDIF

In short, let the CA-Clipper Pre-Processor handle the prerequisite
'grunt work' for me.

Quote:
> >'Ease of use' is critical.
> >Visual representation (linking) of tables & keys would be required.

> I think there are "ease of use" types and "give me power" types.  I'm
not
> certain there is an "easy and powerful" solution.  Take for instance
> Microsoft's ADO (ActiveX Data Object) model.  Might be considered
"not easy"
> but it is infinitely flexible.  A TBROWSE on steroids.

> I think it is fair to say that a visual representation can be placed
atop any
> DBMS, it is just a presentation layer that accesses the engine
below.  One
> can't however place the GUI layer on top of a non-existent DBMS so
we'll need
> the DBMS first.

Very true.  I realize the "GUI layer" is an evolutionary progression of
the capabilities of the core (DBMS) engine.

Although I think it's also fair to say the current (DBMS) products on
the market have gained considerable market acceptance due to the
"Visual" Dev. and Design tools available for those products, and the
amount of productitivy those tools afford at the Dev. and Admin. levels
(vs. manual coding and Design).  In context, it wasn't so long ago one
had to have such targeted training as to be certified a 'specialist' in
DB Development / Administration, the Visual tools currently available
have lessened the 'specialization' requirement to an extent where a
developer can be productive with a DB product in a fairly short
timeframe.  Not an 'expert', but productive.

Quote:
> >'Code generation' would top it off.
> >Generate the necessary 'SQL' code for me, let me 'cut-n'-paste' back
> >into the legacy app.

> Again it is a tool thang!  I'm not certain how it knows what you want
but
> if you select fields from a list and it generates SQL there will be a
dozen
> tools for every DBMS currently on the market.

Generalization on my part. :(  You're right, it's a 'tool thang.'

I have (XYZ DBMS).  I know for (90%) of application development, the
access methods used by the DBMS engine are sufficient to maintain good
performance characteristics in the application.  As far as the
application is concerned, the (SQL) can either be directly 'generated'
(coded) in the application or "Served" from an alternate source (DBMS
table / abstracted Objects /Middle-tier App. Server / etc.).

There are areas in (10%) of the app. which are better served by faster
(optimised) (SQL), the (10%) being direct-coded (or "Served").  The
ability for (XYZ DBMS) to generate the base (SQL) code needed to
incorporate into (and optimise) the application is the ability I'm
referring to.

Tom, from my perspective *productivity* is the most important item I'm
looking for at this point.  In these 'mind-numbing' days of multiple
OS's, Development Languages, Office Suites, Hardware platforms, and the
never-ending 'Service Pack', there's just too much to digest and keep
up with, let devote any real measure of specific concentration to.

If the product is relatively easy to use, doesn't radically alter (or
break) what I got, doesn't require me to devote an immeasurable amount
of time on the learning curve,  and affords measurable (tangible)
benefits, I'm all for giving it a try.

Regards,
Bob

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Sat, 05 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Quote:

>RDD Code:

>// Order Record update:

>SELECT ORDERS
>Seek ( nOrdNum )

>IF FOUND()
>   IF RECLOCK(5)
>      REPLACE ... WITH ...
>      REPLACE ... WITH ...
>      // or ..
>      RecUpdate( aOrders_ )  // Scatter-Gather() array..
>      COMMIT
>      UNLOCK
>   ELSE
>      Alert("Could not lock record for update at this time.  Retry ?" )
>   ENDIF
>ELSE
>   Alert( "Critical Error!  Order Record no longer exists !" )
>ENDIF
>// SQL Order Record update:

>SELECT ROW FROM COLLECTION oOrders FOR ( oOrders.OrdNum IS_EQUAL_TO
>(nOrdNum) )

>IF oOrders.NotFound()   // ( oOrders.SelectedRowCount() == 0 )
>   Alert( "Critical Error!  Order Record no longer exists !" )
>ENDIF

>IF oOrders.SelectedRowCount() > 1
>   // Handle accordingly: LOG AS ERROR - ROW MERGE/PURGE
>ENDIF  // Should only be (1) Row for each (unique) Order..

>IF oOrders.CanTransLockRow() // Physical or Deferred (Trans) lock ..
>   BEGIN TRANSACTION LABEL "oOrders"
>     // Option (A)
>     UPDATE ROW USING ARRAY aOrders_    // Scatter-Gather() array ..
>     // Option (B)
>     UPDATE ROW USING OBJECT oOrders.SelectedRow()  // Collection..
>   END TRANSACTION

>   // replicate to alternate DBMS else Rollback the Transaction !
>   IF TRANSACTION "oOrders" SUCCEEDED // ( oOrders.TransSucceeded )
>      COMMIT TRANSACTION "oOrders" TO DATABASE
>      STORE TRANSACTION "oOrders" TO LOG
>      REPLICATE "oOrders" TO ( Some other DB ) USING LOG
>   ELSE
>      ROLLBACK TRANSACTION "oOrders"
>      Alert( "Order Record update failed! " )
>   ENDIF
>ELSE
>   Alert("Could not lock record for update at this time.  Retry ?" )
>ENDIF
>In short, let the CA-Clipper Pre-Processor handle the prerequisite
>'grunt work' for me.

I think this points up what I was getting at.  There is nothing in the Clipper
code that implies that duplicate keys cannot exist yet the SQL code enforces
that rule.  Not that it shouldn't but that is certainly part of what a
pre-processor couldn't do, invent stuff.

And (I know it is an example but) what is an oOrder?  In the Clipper code it
is probably a loosely coupled bunch of LOCAL variables that follows the
REPLACE commands.  They might include the return values of a function call,
DATE() or NextInvoice() and maybe even an expression like "UPPER( LName )  +
UPPER( FName )".

For that matter I'm never surprised to see:

        LOCK
        REPLACE <blah>
        REPLACE <blah>
        compute, compute, compute
        REPLACE <blah>
        ask question
        REPLACE <blah>
        UNLOCK

It is only that I question any automated solution that has fairly strick rules
to do a good job in a situation that has virtually no rules.

Quote:
>If the product is relatively easy to use, doesn't radically alter (or
>break) what I got, doesn't require me to devote an immeasurable amount
>of time on the learning curve,  and affords measurable (tangible)
>benefits, I'm all for giving it a try.

I'm an "out with the old... in with the new" kind of person.  Writing in S'87
would almost kill me.  Writing in 5.x is about as boring as I can take at this
point.  Give me browser technology... <g>

Tom

---> Learn a little something at http://www.leylan.com
---> Now in French, German, Italian, Portuguese and Spanish



Sun, 06 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Quote:

>It is only that I question any automated solution that has fairly strick rules
>to do a good job in a situation that has virtually no rules.

"Strick" ???

---> Learn a little something at http://www.leylan.com
---> Now in French, German, Italian, Portuguese and Spanish



Sun, 06 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?



Quote:

> And (I know it is an example but) what is an oOrder?

Object "oOrder" is an Table "Collection" object containing all known
info. about the "ORDERS" Table contained in DB (x).  This includes
Field Struct., Keys, etc.
--------------
A (primary) function of a Table Collection object is to emulate a
[Table-type] RecordSet in VB ;

"A set of records that represents a single Database Table that
you can use to add, change, or delete records".

By virtue of the Table Collection object containing all known info.
about the Table [ and a reference back to it's parent "oSQL"
(DB-level) Object ], operations on the Collection object automatically
honor (enforce) Table (DB) integrity & security constraints.

---------------

The default view of a Table Collection object is *Global*, all records
in the referenced Table are available when the object is created.

Selection (restriction) of a given collection object is performed
via the SELECT ROW operation.

Quote:
> ... Give me browser technology... <g>

Amen to that. <g>

Regards,
Bob

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Sun, 06 Jan 2002 03:00:00 GMT  
 What features do we want in a DBMS?

Quote:


>> And (I know it is an example but) what is an oOrder?
>Object "oOrder" is an Table "Collection" object containing all known
>info. about the "ORDERS" Table contained in DB (x).  This includes
>Field Struct., Keys, etc.
>A (primary) function of a Table Collection object is to emulate a
>[Table-type] RecordSet in VB ;

But that isn't "transparent."  When you see Clipper code that opens .NTX files
on an ad hoc basis there is no such thing as an ORDERS table.  What I am
trying to point out is that if you already keep things orderly transition to a
DBMS isn't too hard.  If you randomly choose index file names, workareas, and
input & display data between reads and writes all modifications become a pain.

In a nutshell, "easy is relative."

Tom

---> Learn a little something at http://www.leylan.com
---> Now in French, German, Italian, Portuguese and Spanish



Mon, 07 Jan 2002 03:00:00 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Wanted: ADA compilers for DBMS on PC

2. Wanted: Simple DBMS in Tcl/TK

3. wanted: lisp program doing syntactic analysis of a frame langage

4. Win32Forth Wishlist of features wanted.

5. WANTED: Table of Programming Language Features

6. Fault-Prone Ada features wanted

7. Wanted: tree- and feature structure displaying software

8. Bug or wanted (2) and features ...

9. Opinions wanted: vote on new features

10. QUERY: Full-featured LISP Interpreter Wanted

11. Doing assembly and really doing assembly

12. Doing assembly and really doing assembly

 

 
Powered by phpBB® Forum Software