I have a database that has to work with 2 countries, IT and RO.
I have a table called User, that contains also the birthplace.
User
| id | name | surname | birthplace |
| 1 | Test | Test | New York |
I also have 2 tables for the birthplace, one for the IT ones and one for the ROs. I cannot store all the cities in one table because IT and RO have a different gerarchy (region, province, district...). So my first thought was to do a birthplace field for each country, like this:
User
| id | name | surname | birthplaceIT | birthplaceRO |
The problem is that every time a nation is added, I'd have to modify the database and the application. On the other side, I cannot make a "birthplace" table because the IT and RO addresses are not compatible.
So, I cannot do this:
Birthplace
| idUser | country | city |
Because I cannot refer "city" to both the IT cities table and the RO ones.
Suggestions?
EDIT. In my PHP application i'm using Symfony with Doctrine, an ORM, so I NEED the Foreign Key constraint between the User and the CityID!
Instead of storing birthplace in User table, change it to let's name it birthplace ID - it can be simply integer but you can do something more sophisticated and use unique codes (your own or maybe there are "proper" geographical codes).
Then you can have table for each country specific birthplace and join tables based on birthplace ID. This way you can keep each country specific geographical hierarchy in its own table. If you need to add another country - you simply create another table for that country and join it with User.
Related
What is the best practice for naming columns in MySql Database when the test team will be using an ORM tool together with cypress to inject and remove data? - test data will be in JSON while the current DB is in MySQL.
For example, let's say I have a software company that has logins for an admin system (Tech Support staff users), dealers, but I also have customers (Users).
In My Table I have the following columns:
1-dealer
first_name | last_name | address
2-staffuser
first_name | Last Name | address
3-customeruser
first_name | last_name | address
Is this the "sane way"? or should it be:
1-dealer
dealer_first_name | dealer_last_name | dealer_address
2-staffuser
staff_user_first_name | staff_user_last_name | staff_user_address
3-customeruser
customer_user_first_name | customer_last_name | customer_user_address
Your models will have specific names in your return JSON so there would be no confusion on the front end with duplicate property/column naming in diff objects... but also you can alias your columns in sequelize if you needed to... i kind of wonder why you don't just have a user table with a user type column that was equal to either staff/dealer/customer tho if the values are the same
EDIT: I think I worded this wrong. Please read foreign keys as foreign key constraints. I realize I need the client id in the address table, etc.
I have a client table.
id | pref_name | full_name | business_name | etc . . .
I realized the client can have multiple locations/addresses so I have an address table.
id | client_id | name | address1 | address2 | sub_area_id | area_id | province_id | country_id | postcode | etc . . .
Then I realized clients can come from multiple countries so I added:
country table
id | country | code (ISO-2A)
province table
id | name | country_id
area table
id | name | province_id
sub area table
id | name | area_id
So now I realize that I don't need all of sub_area_id | area_id | province_id | country_id in the address table.
From sub_area_id I can get the rest with a join query, however, there will not always be a sub area id. There WILL always be an area id. I guess I do need sub_area_id | area_id but can remove province_id | country_id from the address table
What I am not sure of is do I need foreign keys for the country, province, area, sub_area table with each other?
It seems that if a country is deleted so should all relating data in the other tables, but I am pretty sure that a country will never be deleted. Same for provinces, areas, sub_areas. Is it a waste of time implementing foreign keys?
Also a client might be disabled (not deleted because it would affect historic data) so can a foreign key also disable the client addresses, or is it just not necessary to disable them? Again, its probably not best to delete them as the client may resume later on.
Any suggestions for improvement on my structure?
TIA
Yes definitely you need foreign key to refer the address of client. if you have not the id of the client in address table, you have no way to retrieve address of your client from address table
I have the following data in my database:
I am building a report where I have separate sections for County, State, and Country that display the distinct values for that column. For example, the Countries and States sections of the report would look something like:
Countries States
--------------------------- -------------------------
| Country Name | Primary? | | State Name | Primary? |
--------------------------- -------------------------
| USA | Yes | | GA | Yes |
--------------------------- | VA | No |
-------------------------
I have been trying to accomplish this using tables, but am having trouble getting the data as distinct values. Is there a way to do this other than by creating a separate dataset for each type of data (State, Country, etc.)?
I've used your data to get your expected results by adding two tablix to the report and groping on Country and State fields.
In the Primary? column I used this expression for Country table:
=IIF(
SUM(IIF(Fields!Primary.Value="True",1,0),"Country")>0
,"Yes","No"
)
For State table create a row group by State field and use this expression:
=IIF(
SUM(IIF(Fields!Primary.Value="True",1,0),"State")>0
,"Yes","No"
)
This is the preview of both tables.
The Country and State tables must have the Country and State Row
Groups.
UPDATE:
In order to get the correct presentation avoiding multiple rows, you have to delete Details group as you can see in the screenshot there is only one group in Row Groups: Country
Let me know if this helps.
I have a db schema where user data is stored using foreign key references , these foreign keys are admin defined . Also , there is some data which is stored without primary keys , however I have other constraints in place to avoid redundancy and other issues .
Due to the requirements of the application when a user 'updates' their info I have to delete all user records from the 'updated' table and reinsert all the user's records again . (I have looked into all other options)
Now because of my search solution (solr) , I need to track changes to the user data (updates/deletes) . I am planning on having a view to compare the last committed data to the real time data . I am fearful of how sustainable it would be to have a stored procedure running every 20 minutes or so , is there a better way of tracking data with SQL ?
You could create a change table that contains the same columns as the original table plus another column called "UpdatedOn." Then set up a trigger to write to this change table the original values when the original table is changed.
Example:
Original Table:
Name | Address | City
Jane Doe | 1 Main St. | New York
Change to Original Table:
Name | Address | City
Jane Doe | 2 Smith St. | Dubuque
...which triggers an insert to the Change Table:
Name | Address | City | UpdatedOn
Jane Doe | 1 Main St. | New York | 2012-01-01
There is information about using triggers in mysql here: http://dev.mysql.com/doc/refman/5.0/en/triggers.html
I have two entities: Event and Location. The relations are:
1 Event can have 1 Location.
1 Location can have many Events.
Basically I want to store events. And each event is hosted in a specific location. When I say specific location I mean:
Street, Number, City, Zip Code, State, Country
I basically have a design question, that I would like some help with:
1 - Right now I am thinking on doing the following:
Event table will have a location_id that will point to a specific location row in the locations table. What happens with this is that:
I will have many repeated values in each row. For example, if an event is happening in 356 Matilda Street in San Francisco, and another one is happening in 890 Matilda Street in San Francisco. The values Matilda Street and San Francisco will be duplicated many times in the location table. How can I redesign that to normalize this?
So, basically I would love to hear a good approach to solve this question in terms of a relational database, like MySQL.
If you want a strictly normalized database, you could have a table for street names, another for cities, another for states, and so on. You might even have an additional location table that holds unique combinations of street, city, and state; you'd add rows to this table each time an event occurs at a previously unknown location. Then each of your events would reference the appropriate row in the location table.
In practice, though, it's sometimes better simply to store the location data directly within the events table and tolerate the extra memory usage; there's always a trade-off between speed and memory use.
Another consideration: what happens if a street is renamed? Do you want old events to be associated with the old name or the new name?
Each location in the locations table should be uniquely identifiable by its PRIMARY KEY. Records in the events table then reference their associated location with column(s) that contain the value of that PRIMARY KEY.
For example, your locations table might contain:
location_id | Street | Number | City | Zip Code | State | Country
------------+----------------+--------+---------------+----------+-------+---------
1 | Matilda Street | 356 | San Francisco | 12345 | CA | USA
2 | Matilda Street | 890 | San Francisco | 12345 | CA | USA
Then your events table might contain:
event_id | location_id | Date | Description
---------+-------------+------------+----------------
1 | 1 | 2012-04-28 | Birthday party
2 | 1 | 2012-04-29 | Hangover party
3 | 2 | 2012-04-29 | Funeral
4 | 1 | 2012-05-01 | May day!
In this example, location_id is the PRIMARY KEY in the locations table and a FOREIGN KEY in the events table.
Your Locations table should have a unique ID such as 1=Matilda Street, 2=Market Street - one record for each possible location NO DUPLICATES, then your Events table should have a location ID that uses one of those IDs - again, one for each event, no duplicate.
You can then join them like this;
SELECT events.event_name, locations.location_name
FROM events
JOIN locations on locations.location_id = events.location_id
The duplication is very normal because each of them is an unique location. And beyond that, the design you think is very usable when you try to filter the places in san francisco.