How do i build a relationship between database and a database? - mysql

I have a bunch of zip codes. Each zip code has its own database. The tables in each database are only related to that particular zip code. I also have a customer database. Each customer can only be assigned to one zip code. Being assigned to a zip code, that customer has access to all the features/TABLES of that particular zip code.
If I had all the zip codes and customers in one database I could easily join the tables using Foreign Keys / Primary Keys. But I feel it is more organized to keep each zip code separate as its own database. I choose it this way because each zip code is completely unique from one another.
I am new and have been watching tutorials but I only see table to table solutions. I would like to know how can I build a relationship between databases.

To answer your question: there is no way to establish relation between data in different databases.
Your design doesn't make things more organized; on the contrary, by creating multiple databases with similar - and related - data, you make it much more difficult to establish connections and to work with the data in an effective way.
Consider moving all data into one database, and adding "zip_code" field to tables so you can easily select data from each zip code as needed.

A "database" in MySQL is just a schema
You can query between and have foreign keys between schemas, just use the fully qualified name schema_name.table_name
I can't see a good reason to have zip codes spread among schemas. They should all be in the same table with a "country" column.

Related

How to create this structure in mysql databases

I need to create such a structure, there is a category of products, each category stores its own information, for example, be entered phone information when selecting a phone category, computer information must be entered when selecting a computer category, How to create this structure in a clean database? , how is it done in a real project?
Before creating a 'structure' in a DB you need to design your Entity-Relationship Diagram.
This means that you need to decide the Entities of your problem, these would be your tables later in the DB, the Relationships between the entities, these have multiple ways that can be depicted in the tables based mainly on their cardinality and then the properties of the entities, which will be the fields of the tables in your DB.
I think that you need to start from that, create the ER Diagram and then try to model it into the DB.

Inserting JSON data line by line into an SQL table

I have a JSON file that stores the information about a bunch of recipes, like cuisine, time, the ingredients, instructions, etc. I am supposed to transfer all the data to a MySQL table with the relevant headings.
The "ingredients" and the "instructions" are stored like this:
The instructions and ingredients have several "lines" , stored as a list.
How can we store the ingredients and instructions in a MySQL table, in a line by line format?
something like:
instructions
inst1
inst2
..
The JSON file was created using a python program using the beautiful soup module.
PS: I am very new to both SQL and JSON, so I unfortunately dont have anything to show under "what I tried"...Any help will be appreciated.
Rather than give you the exact answer, I'll give you the process I use to determine a database structure. You're using a relational database, so that's what I'll talk about. Its also good to have a naming convention, I've used CamelCase here but you can do whatever you want.
You mentioned you were using python but this answer is language agnostic.
You've chosen quite a complex example, but I'll assume you understand how to create a table, and use primary keys and foreign keys. If not, maybe you should do something simpler.
Step 1 - Figure out what the entities are
These are the real-life entities which need to represented as database tables. In this case, I'm seeing 4 entities;
Recipe
Keyword
Ingredient
Instruction
Each of these can have a table in MySql. Give them a Primary key which follows a naming convention.
Step 2 - figure out the relationships
It looks like keywords are shared between multiple recipes, so you'll a many to many relationship - this means there's going to be an extra table,
RecipeKeyword
This is just a link between Recipe and keyword to avoid redundancy. It has two foreign keys, RecipeId and KeywordId. At the moment its just a dumb object. In other situations like this, its common for an application to need information about a join - for example, who linked the two things together (consider users, permissions, and a join table with information on who granted the permission)
The other entities are one to many - each will need a foreign key, RecipeId
Step 3 - design each table
As well as having several lists, your Recipe object has some properties. These can be in its table. Most of them are strings in your data, although there are better ways to store things we can keep this simple.
The other entities just have a text field, from your screenshot, only the Recipe has properties.
For this system, you'll need to first insert all Recipe and Keyword objects. There is a common pattern in relational databases where in insert a record, and get its ID so you can insert more stuff which references it.
Step 4 - find a python mysql library
I don't know of one but google will help you find it. The documentation should include the basics of querying.
Step 5 - Insert your data
Here is some psudocode
FOR EACH recipe
INSERT the recipe, and get its ID
FOR EACH keyword
IF the keyword does not exist already
INSERT the new keyword and get its ID
INSERT a record into RecipeKeyword with RecipeId and KeywordId
FOR EACH ingredient
INSERT the ingredient, give it RecipeId as a foreign key
FOR EACH instruction
INSERT the instruction, give it RecipeId as a foreign key
That's it. From here you can select with joins - To form what we're seeing above, you might need to do 3 seperate queries and merge them together into a record object on the python side to reproduce the original structure.

Does IntelliJ has a function to visualize the relationship between two specific tables in a database?

I'm working with a big mySQL database in IntelliJ.
I'm trying to join two tables which aren't in a direct key-relation to each other. Hence I have to join over multiple tables.
Because I barley know the database scheme, I can't find out these tables in a appropriate time. I know that IntelliJ has a function which can visualize all tables with their relations within the database but does it also provide a function where I can find out all tables in between two specific tables?
You can get help from Intellij partially for your task, using the visualization feature as follows-
The relationship between tables are clearly shown.
For your question, you need to check the primary and foreign keys for each table which are easy to know as they are highlighted.
Traversing them you can find the relationship.

Separate database table for user?

Here is a question from a newbie. I need to store music data(URL, artist ...) for each user. Should I put all data in one single table with distinct keys for each user. Or maybe it is good idea to have separate tables for each user.
I am making an online player.
Thanks in advance
You will create huge database if you are going to create seprate table for each user, make a table structure that will contain entries of all user in single table....
Create a single table with different user privileges for ex create an
group column table and provide different grouids to different users
e.g. groupid =1 for admin ,2 for normal user etc.
A separate table for each user is not appropriate.
You need one table for the music data (URL, artist, ...).
If the only item you store about users is the name, you can put that into the music data table as well without violating database design principles too much.
As soon as you store additional information about users (e.g. password, e-mail address) you need a second table for the user data and connect the music data to the user data via a foreign key in the music data table (or, in case of a n:m relation, a third table).
If you are looking for further information about database design, keywords are functional dependency and normalization.
Enhanced relationship diagrams may help you in designing your database. It might be worth mapping out your proposed database using these diagrams before you implement them.
This is a good tool to make sure you have a correct database design for you and as previously said below deal with functional dependency and normalization.
This is a good website to help you if you haven't done this before: http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html

how to migrate document oriented db to mysql

I can find all over the web articles to migrate an existing MySQL database to a SimpleDB or CouchDB or what so ever.
But If I go ahead and migrate my millions of records to Riak or CouchDB, is there any way to migrate back?
Would it be possible in theory to regenerate all the relations between my data that has no clear indexes to a relational database and regenerate all the relations?
Example:
I have two tables in MySQL one is person and one is job, job is related to person - in one to one relationship.
If I switch that to couchDB, person document will have the job defined as text value for the key "job"
inserting this relation in couchDB is very simple from MySQL. Select.. combine then dump one person object.
Now, split one person object into two objects - and find the correct key for the certain job. How?
Any help is appreciated!
Here's my idea:
For the example, I'd start with looping through all records to create a list of jobs, then adding those to the jobs table. Then do a loop again, this time matching the 'job' in persons to the newly created job in mysql and fetching the id, adding that id in the person table 'jobid' foreign key field.
This way of analysing the data could probably be generalised in a script, but you would need to present it a 'translation' array or something, defining the relations.
To answer your question, yes, in theory it should be possible.