[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