Hi all,
I've got a bunch of tables now, and I'm starting to lose track of table
relations. Is there a command, or even a program, that I can use to
visually see my relationships?
Thanks in advance,
Tony.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tony Peardon schrieb:
> Hi all,
>
> I've got a bunch of tables now, and I'm starting to lose track of table
> relations. Is there a command, or even a program, that I can use to
> visually see my relationships?
>
You could try something like DBDesigner from fabforce
Regards
Stefan
> Thanks in advance,
>
> Tony.
>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
iD8DBQFD9O/kyeCLzp/JKjARAgvnAJ9akEicCm4WZIiSbIoNm2RaBIQWuQCf eKpC
onzDmjRMeDQfa4Md2rvu8IY=
=Qenm
-----END PGP SIGNATURE-----
Tony Peardon wrote:
> Hi all,
>
> I've got a bunch of tables now, and I'm starting to lose track of table
> relations. Is there a command, or even a program, that I can use to
> visually see my relationships?
>
> Thanks in advance,
>
> Tony.
>
>
>
>
Aqua Data Studio has several ER type diagrams available. Find it at
http://www.aquafold.com/
Tony Peardon wrote:
>
> I've got a bunch of tables now, and I'm starting to lose track
> of table relations. Is there a command, or even a program,
> that I can use to visually see my relationships?
Relationshpis are not stored within the database; rather, they are
defined on per-query basis using JOIN clauses. Programs that allow you
to visualize relationships simply store your "notes to self" and help
you build queries based on those notes. So, in my opinion, the best
(and vendor-independent) solution is to simply document your database
design, and not just the relationships, but purpose of tables and
fields as well.
Cheers,
NC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NC schrieb:
> Tony Peardon wrote:
>> I've got a bunch of tables now, and I'm starting to lose track
>> of table relations. Is there a command, or even a program,
>> that I can use to visually see my relationships?
>
> Relationshpis are not stored within the database; rather, they are
> defined on per-query basis using JOIN clauses. Programs that allow you
> to visualize relationships simply store your "notes to self" and help
> you build queries based on those notes. So, in my opinion, the best
> (and vendor-independent) solution is to simply document your database
> design, and not just the relationships, but purpose of tables and
> fields as well.
>
Thats not complete true. If you're using a RDBMS which supports foreign
key constraints you're able to visualize at least them and they should
represent the relations.
In fact I fully agree to your statement, that documentation is one of
the most important things.
Regards
Stefan
> Cheers,
> NC
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
iD8DBQFD9cEUyeCLzp/JKjARAueYAKCBKX6imW6DaxQD6t8KzhLFLJDKVwCg wwZu
XVIfGHv3TNC5+xYxIhJn1oQ=
=fI8s
-----END PGP SIGNATURE-----
"Stefan Rybacki"
news:45ltojF7djm3U1@individual.net...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> NC schrieb:
>> Tony Peardon wrote:
>>> I've got a bunch of tables now, and I'm starting to lose track
>>> of table relations. Is there a command, or even a program,
>>> that I can use to visually see my relationships?
>>
>> Relationshpis are not stored within the database; rather, they are
>> defined on per-query basis using JOIN clauses. Programs that allow you
>> to visualize relationships simply store your "notes to self" and help
>> you build queries based on those notes. So, in my opinion, the best
>> (and vendor-independent) solution is to simply document your database
>> design, and not just the relationships, but purpose of tables and
>> fields as well.
>>
>
>
> Thats not complete true. If you're using a RDBMS which supports foreign
> key constraints you're able to visualize at least them and they should
> represent the relations.
yes. the fact that it's stored in the RDBMS allows you to use a program
like Aqua to generate ER diagrams with lines between tables, showing the
keys that have the relationships. When you create a table, the
relationship is created as follows with the keyword REFERENCES:
CREATE TABLE `dbo`.`categoryroots` (
`cat_id` int(10) unsigned NOT NULL default '0' COMMENT 'copy of cat_id
from categories table',
PRIMARY KEY (`cat_id`),
FOREIGN KEY (`cat_id`) REFERENCES `categories`(`cat_id`) ON DELETE CASCADE
ON UPDATE NO ACTION,
UNIQUE KEY `ix_crcat_id` (`cat_id`)
) ENGINE=InnoDB;
> In fact I fully agree to your statement, that documentation is one of
> the most important things.
>
> Regards
> Stefan
>
>> Cheers,
>> NC
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (MingW32)
>
> iD8DBQFD9cEUyeCLzp/JKjARAueYAKCBKX6imW6DaxQD6t8KzhLFLJDKVwCg wwZu
> XVIfGHv3TNC5+xYxIhJn1oQ=
> =fI8s
> -----END PGP SIGNATURE-----
Jim Michaels wrote:
>
> When you create a table, the relationship is created
> as follows with the keyword REFERENCES:
> CREATE TABLE `dbo`.`categoryroots` (
> `cat_id` int(10) unsigned NOT NULL default '0'
> COMMENT 'copy of cat_id from categories table',
> PRIMARY KEY (`cat_id`),
> FOREIGN KEY (`cat_id`) REFERENCES `categories`(`cat_id`)
> ON DELETE CASCADE ON UPDATE NO ACTION,
> UNIQUE KEY `ix_crcat_id` (`cat_id`)
> ) ENGINE=InnoDB;
This only works on InnoDB tables; moreover, the ON UPDATE action on
foreign keys is only available in MySQL 4.0.8 or newer...
Cheers,
NC