[Solved] Need Help whether to have split database

[Registry]

This is my first venture here - please be gentle
A small equine registry needs a database created: which I tried to do but says maximum size is 128 and this is over it! How can I show only the tables and not the forms? this should then attach - there are about 70 tables
I need advice if this database needs to be split [and if so, how to do the split] with the person and financial tables in one database and the horse tables in the other split part of the database. The person would be member id, owner id, breeder id, and then dues, and all the tables which had to be created for fees sent for different actions, etc. Sounds complicated but it is actually very simple. The fees however have to be credited to the member id account and to the horse id record.

Additionally, have no way to test this database to see if it truly works other than to know the tables will accept data. The database is to be loaded onto a MySQL port on an Apache server with Site Guard. Tried going with a job freelancer company and not one person responding stated any knowledge of Open Office Base. feel like this.

Any suggestions, ideas where/who to go to, etc?

[Registry]

Since requesting help there have been no replies, so having read here on this wonderful forum for at least two years, know this is not a good sign.

What have I failed to include? What should I have explained better?

I know this is a large database and worry about corruption, loss of data, all the normal stuff goes with such a database. We have carefully not loaded any data into the tables until we are sure of the design.

Anyone?

[Registry]

Let's see if these will upload

they did load per below
My concerns are the present registration system has been overtaxed, through most likely, age, the original was done in the early 1990's, then subsequent there was sometime of change in 2011 and from then to 2019 there have been more versions. Appears, since not on the administration part doing changes, revisions, adaptations is there was no way to make changes, too rigid. And I fear with a split database it will be very hard for changes in tables, design, fields, etc, in short anything and everything

most of the input for this group is going to be volunteers - so yes, those volunteers will have instructions but unless someone special shows up out-of-the-blue won't be an IT trained, knowledgeable person

the basic registration section, the horseID, has 40 tables and one-third of them are connected to like head markings, hoof color, leg markings, etc

the person section has owners, breeders, members, city, address, phone, all that stuff
then the financial section is small but because of normalization there are plenty of tables - needed is a way to know what is being paid for in the registration system and the membership dues section so it can be applied accounting wise.

Is this, with all the tables involved, too big? Can it be managed safely, accurately?

[UnklDonald418]

The fees however have to be credited to the member id account and to the horse id record.

Taking that into consideration, unless you have a well designed strategy for keeping the two databases synchronized I would not recommend splitting the tables into two databases.
There are some tables that look suspicious, particularly "StateCode and Canada Table" with 60+ columns of VARCHAR(50) and the "Color Code Table" but without knowing details of the data set it would be difficult to offer much advice on the design of the tables,
Also, what you have presented has no defined relationships which also hampers our ability to comment on the design.

Can it be managed safely, accurately?

That depends not only on the design of the tables, but also on the design of the data entry forms which you have not presented.
It is obvious you will need multiple forms to enter/edit all those bits of information, so you need a strategy to manage those forms so that there is a logical order for the users to follow.
ListBoxes are a tool that can help simplify and increase accuracy when entering data into Foreign Key fields, Likewise, ComboBoxes can help simplify and increase accuracy when entering data into Text fields that contain repeating string values.

We have carefully not loaded any data into the tables until we are sure of the design.

To have any hope for success, a significant amount of testing.will be needed. Table and form design often needs to be modified after some data entry has taken place. Fortunately, the Copy Table dialog in Base has a number of options that can sometimes help when table modifications are needed and Base forms generally are easy to edit.

[Registry]

Thank you so much. Will start to pull this apart and attempt to address the areas you pointed out.

We have to list all the States and Provinces in Canada because these can be used in the Search/Query process for how many of this breed are in any state or total for the country.

The ColorCode table is for the color of the foal at the time of registration.

Did not realize you would need also the Forms - and I will have to find out what are Combo Boxes and List Boxes! Most of the Forms do have the "First Record, Next Record, Previous Record, Last Record". There are Forms, one for almost every Table except where there is a parent Table in normalization.