(not solved but dead) Multiple tables with same Primary ID

[NJ0E]

Can it be done? I am a HAM operator. I want to make my own logging databse. I will hae at least three seperate tables with informaiton. Can I use the same primary key in all three (it would be operators call sign -- they are unique to each operator).

I'll probably have more questions as I go. I did work with Access along time ago.

Thanks for any assistance.

Joe Carney
NJ0E

[bobban]

I believe so. This post by Villeroy has an attachment demonstrating two tables sharing a primary ID, and it should extend to three if you want.

If this has answered your question please go to your first post and use the Edit button, and add [Solved] to the start of the title. You can also use the green tick icon.

[NJ0E]

I don't think that is what I was trying to describe. Not even sure if I should be working in OOs DB now. seems that he was advising to use MYSQL.

What I envision:
Table one -- main table with most of my radio contact info
Table two -- all of the QSL information for all the contacts
Table three -- address' of all the contacts.

I am headed this was due to the fact that long time ago in a MS Access class we were told not to have one massive table -- better to use smaller tables and link the relationships. I just cant figure out how to link all of the tables together. Right now the information is all in one table.

Again,

thanks for the assistance.

Joe

[bobban]

I am headed this was due to the fact that long time ago in a MS Access class we were told not to have one massive table -- better to use smaller tables and link the relationships. I just cant figure out how to link all of the tables together. Right now the information is all in one table.

I believe that is what Villeroy is doing in his example: "OneToOne.odb" (the post at the bottom of page one on that thread)

He has two tables linked by the primary key. The end result is that he has a form which has an embedded sub-form. The sub-form displays the data of the second table, and as you navigate through records the form and sub-form are kept in sync by the one to on relationship of the primary key.

[keme]

I don't think that is what I was trying to describe. Not even sure if I should be working in OOs DB now. seems that he was advising to use MYSQL.

What I envision:
Table one -- main table with most of my radio contact info
Table two -- all of the QSL information for all the contacts
Table three -- address' of all the contacts.

I am headed this was due to the fact that long time ago in a MS Access class we were told not to have one massive table -- better to use smaller tables and link the relationships. I just cant figure out how to link all of the tables together. Right now the information is all in one table.

Using native OOo Base database is OK for prototyping and workable for some "real work" as long as only a single user at a time is accessing the data. MySQL is more secure, efficient, and handles multiple concurrent access easily, but requires some additional setup, and it's often harder to modify table structure.

Splitting the table into several smaller tables is often a good idea. The best way to split it is not always obvious. Tables are normally split to satisfy conditions in defined "normal forms" (NF). Starting with 1NF (First normal form) and going to 6NF. For most applications, 3NF (or the slightly more restrictive BCNF) is sufficient, and many tables are already in 2NF or 3NF once 1NF is satisfied. If this sounds familiar, go back to the notes from your Access class and read up. If it doesnt, search the web. (Wikipedia is a useful starting point for normal forms.)

If normalizing doesn't dictate splitting of your tables, then it's OK to keep all in one table. Access (at least the versions I've worked with) won't allow more than 255 fields in a table, but I haven't yet met any limitation in OOo Base. (Have tested with 1000+ fields, just to see if it was possible.)

Using 1:1 relationships is rarely dictated by normalizing up to BCNF, but is sometimes useful anyway. In particular:
- If there is secondary data only for a small number of entities.
- If you need to add fields to an existing table, but it's not possible to alter the structure of that table.
- For temporary data, or other instances when it's more or less impractical to modify a table.