[Novalug] Using DBDesigner4 for DBMS other than MySQL

Igor Birman igor_birman@yahoo.com
Tue May 15 22:33:17 EDT 2007


I guess it depends on what you are using the tool for.  I tend to keep my database diagrams simple - just the keys and the joins.  I document the constraints and triggers through other means.  

I have looked at tools that do more.  I went through CASE tools, then 4GL systems, played around with the Rational tools, had something that came before Rational - Knowledgeware, then Key for Enterprise, and probably a few others.  All the tools suffer from the same problem, either you live 100% in their world or they are not worth it.  There was a time when you could live with a single set of tools, but that no longer exists.  What works for me now are tools that help communicate with everyone at a high level to design a good system.

So, given that, this tool is great for putting together and sharing a simple high level design.  I hope the MySQL version of it stays free!

Igor



Peter Larsen <plarsen@famlarsen.homelinux.com> wrote: Theodore Ruegsegger wrote:
> Ken quoted me:
>>>> After all SQL is SQL and the only DBMS-specific syntax is in
> 
> and commented:
>> Unless it's PL/SQL.
> 
> Well, if Javascript is Java, then I guess it's reasonable to say that
> PL/SQL is SQL. ;-)
> 
> But I would say instead that PL/SQL is a procedural language (which
> SQL is most definitely not). It happens to be aimed at SQL-aware DBMS
> (PL/SQL is a proprietary Oracle language but other DBMS have similar,
> in name and description, languages) but isn't SQL itself.

Well, this is one of the reasons a lot of these tools fail on my table. 
They simply do "basic SQL" and databases today are way beyond that 
point. To me, a model contains constraints, triggers and other business 
process rules that make the model work. These are mostly implemented in 
a procedural programming language and becomes an integral part of the 
database design. It's really key to be able to include at a very minimum 
triggers, but most likely procedures/packages (in Oracle) as part of the 
common API that most likely is shared among the tables.

Simple code to deal with sequences and security rules are important, 
just as important as modelling views is. They're all necessary to have a 
functional database schema.

Of course there's types of API that's specific for the application use, 
such as batch processing etc.  Those aren't an internal part of the 
database schema; and should be placed in a separate database schema anyway.

Btw. Java and JavaScript shares a LOT more than SQL and PL/SQL does :)

> This fills a need for tasks that are more easily handled (or
> understood) procedurally.

Unfortunately there are tasks today that cannot be controlled via SQL, 
including that of complex constraints (ie. saying that a value must be 
located in a table where the look value is computed or more complex than 
a simple "column to column" mapping).

--
   Peter Larsen
begin:vcard
fn:Peter H. Larsen
n:Larsen;Peter
org:Ciber Inc;Federal
adr:Suite A515;;7900 Westpark Dr.;McLean;VA;22102;USA
email;internet:plarsen@famlarsen.homelinux.com
title:Principal Consultant
tel;work:703 610 6442
tel;home:540 847 0856
x-mozilla-html:FALSE
url:http://ciber.com/federal
version:2.1
end:vcard

_______________________________________________
Novalug mailing list
Novalug@calypso.tux.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/novalug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.firemountain.net/pipermail/novalug/attachments/20070515/813c93c5/attachment.htm>


More information about the Novalug mailing list