Web forum is in read-only mode. Login as active registered customer for write access
  Forum Search   New Posts New Posts

Support For Database Triggers

 Post Reply Post Reply
Author
Calford Dalton View Drop Down
New Member
New Member
Avatar

Joined: 11 Sep 2010
Posts: 12
Post Options Post Options   Quote Calford Dalton Quote  Post ReplyReply Direct Link To This Post Topic: Support For Database Triggers
    Posted: 11 Sep 2010 at 8:56pm
The tool needs the ability to add servers/databases to the diagrams including database triggers.

Modern E/R diagrams require modelling all the business rules and relationships.  Servers have server version/configuration/aliases etc.  

Databases have triggers, configurations (including global variables).

Middle ware products, agents and replication processes are all part of the overall design criteria.

Applications, Forms etc are also all needed to be diagrammed.

How would I create/diagram database triggers/schema?
Back to Top
Ricardo View Drop Down
New Member
New Member
Avatar

Joined: 12 Jul 2010
Posts: 18
Post Options Post Options   Quote Ricardo Quote  Post ReplyReply Direct Link To This Post Posted: 16 Sep 2010 at 3:11pm
Data Modeler does have support for table triggers, they are found inside "Triggers" tab at table editor.
However, the purpose of Data Modeler is modeling the tables and objects of a single database. For now, the product doest not provide any feature to manage servers, databases, forms, etc.

--
Ricardo Samila
TMS Software Team
http://www.tmssoftware.com
Back to Top
Calford Dalton View Drop Down
New Member
New Member
Avatar

Joined: 11 Sep 2010
Posts: 12
Post Options Post Options   Quote Calford Dalton Quote  Post ReplyReply Direct Link To This Post Posted: 17 Sep 2010 at 9:15am
Firebird has triggers on the database itself - on connect, on disconnect, on transaction start/commit/rollback etc.

This has been available for the past few versions. 

Database triggers are very different from table triggers both in scope and implementation - very often with database triggers you are using out of transaction processing to record events, even when the triggering transaction is rolled back.

Modeling tables, without considering their relation to other elements in the design, is a waste of time.   No N3+ table relies solely upon itself.    You have security roles, triggers, procedures, views, domains, replication settings, logging settings, indexes, keys, functions and filters that all can impact the design.   The tables could be in the current schema, current database, different schema, different database, different server.

On top of that, you need to track what clients are using what database elements, so that any new design work /refactoring is taken into consideration.

All of these design elements have been considered by diagram software in the past and should be covered in any modern ER tool .


Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down