In trying to create a SQL database that can be queried within java, but I'm not sure how to structure it. Here are my categories:
1. State
2. Cites within each state
3. Venues within each city
4. Specifics about each venue
This might seem simple to some, but I am concerned with the amount of information that will be located in category #4, since that category alone could house the most data. The most important part of this is that I would of course need to query this information in category #4 and return the information. Is it common practice to have a category with a lot of information in it or do I need to break down category #4 even further? Also, another issue I am coming across is that I am using java to create arrays or arrayLists for all this info and I don't know how to get the data from the arrays to mysql. Any info is appreciated.
Creating relational tables for a relational database and querying relational tables in a relational database using Java are two different tasks.
First, let's create the relational tables.
State
-----
State ID
State Name
...
In the State table, you store all the information about a state. The State ID is the primary (clustering) key, and is an auto-incrementing integer.
City
----
City ID
State ID
City Name
...
In the City table, you store all the information about a city. The State ID is a foreign key to the State table. In the few cases where a city is in multiple states, you create a city row for each state. As an example, Bristol, Virginia and Bristol, Tennessee is a city in two states.
Venue
-----
Venue ID
City ID
Venue Name
Venue Type
Venue Address
...
Venue Type
----------
Venue Type ID
Venue Type Description
In the Venue table, you store all the information about a venue. The City ID is a foreign key to the city. You can get the state information from the city row.
In the Venue Type table, you store the various venue types, like hotel, theater, restaurant, retail store, etc.
The only reason you would create a Specifics table is if there are multiple types of specifics for a venue. Otherwise, you can add a Venue Description column to the Venue table.
First, get your relations for your relational tables correct. Then, you can see how to map the relations to Java classes. Classes consisting of lists are probably the correct approach.
Get your code to work with the most direct mapping between your domain objects and your tables. If down the line you realize you're storing too much data in one table, you'll be able to refactor by breaking that data more. But I wouldn't worry too much about having too much data in a table, that's what databases are made for. What you need to think about is how you're going to access that data, and make sure you have proper indexes and primary keys on it.
To insert several rows of data from Java to mysql, search the Web. Java: Insert multiple rows into MySQL with PreparedStatement may be a good start.
Related
everyone! I have two tables that I would like to join via DynamoDb, but since the latter is not a relational db, I don't know how to map the link between the two tables.
In particular, I have a Price List table and a Detail List table that contains the details of the first one. How can I implement one-to-many relationship in java using dynamoDB with Spring Boot?
DynamoDB is basically a key-value store. You only every perform a lookup based on a key. That key may be artificial, not just a user id, but maybe "user_id#product#order" but still it will be a key-based lookup. If you want to use DynamoDB you have to store the data in a way that all queries that you will need will all boil down to basic key-based access (plus some sorting).
You have to do the exact opposite of normalizing your data and splitting relations into multiple tables: you have to de-normalize all your data to store the data and all the relations just in one table, multiple times, with multiple complex artificial keys. See e.g. https://www.youtube.com/watch?v=HaEPXoXVf2k on how to use LSIs, GSIs, how to model your data, how to choose artificial keys, etc.
That means you will not have Item, Order and OrderItem table that you join together, but you will have just one Everything table which may have the fields: userid, username, ordernumber, itemid, itemprice, itemquantity, itemname, orderdate, shippingaddress, etc.
And if you have three items in an order you will have three entries in this table. That means the username will be in the table very often, that means the itemname will be in the table very often and changing them will be difficult but that is how things are if you want to use dynamodb.
That is how you model one-to-many relations, by packing them into a single table and add proper indexes.
If you do have no idea about the current or future access patterns of your data or how to structure your data properly then dynamodb is the wrong tool for you.
The question you are asking gets at the very essence of working with DynamoDB and NoSQL data modeling. It is not as simple as applying your relational database knowledge to DynamoDB. Take a moment to familiarize yourself with the DynamoDB basics before you get too far into solving this problem.
Watch this video about modeling one-to-many relationships in DynamoDB. I would recommend you watch the entire video from the beginning, as it's one of the best introductions to the topic currently available.
I am building a COTs product which records sales data. Since it will be used by different business owners i want to save the sales data to the owner specific tables. So how do i use a single entity to perform operation on different tables based on unique owner id? My core object and business logic is the same. I am just stuck on how to persist data for each owner in a separate tables. I don't want to have it all in one table with owner id as unique. It just creates risk of impacting all the clients data while any update/migration to the table.
Simple question really. This is using JPA on Java and what I what to do is to have a table with and column which can refer to one of two tables. To make this clearer I can have a 'User' table and a 'TempPerson' table. I don't want to pollute my User table (as I use it for security as well, plus has other info as well). Now lets say I have a third table called 'Game'. Now when someone stars a game against someone, they can play against someone in the system already ie. User or someone where they can type a name and new entry for TempPerson is created and used. So the game for player2 (or player1) will be a mapped id to either User.id or TempPerson.id. Now I understand that a determining column may need to be placed into Game to determine what the Id is for but I hope JPA will cater for it somehow. Any ideas will be helpful, i could use inheritance but not sure about it.
Here is another example:
Lets say I have a table which holds information about images => id, resolution, width, height, location, bucket .... id_in_the_table_where_used, table_name_of_where_used. Now, this one table can hold the images for profiles, places, etc... and the profiles, places will have an id referring to the images table, but I also would like the images table to have an id back to where the images is used, which table and which id is using it.
It almost I am asked i 'one to many tables' solution. Although I could have many in between tables etc... Seems overkill to so something quite simple, although many DBAs may be cursing this idea. It does minimise queries, number of tables etc...
Thanks in advance
It is possible to use single FK to target multiple tables. You would have to use #JoinColumn for that
#Entity
public class User{
#OneToOne
#JoinColumn("universalId", targetEntity=Avatar.class)
private Avatar
#oneToMany
#JoinColumn("universalId", targetEntity=Log.class)
private List<Log> logs;
}
This would use universalId column of User's table to lookup related records from Avatar and Log tables
This however is rather anti-pattern, causing a lot of consequences when for example universalId will have to be changed etc. 1 column = 1 FK - go that way.
I have a DatabaseObject in Java which can dynamically retrieve information from a database and store it in key-value pairs (it is just an extended LinkedHashMap).
My DatabaseObject can load, delete, update, and insert values into a table, based on provided columns that match the database table.
I have a "Company" table and a "Category" table in my database, and each company can have multiple categories. I also have a "CompanyCategories" table where each company's category is recorded. These are what the tables look like:
Company
CompanyID, Name
Category
CategoryID, Name
CompanyCategories
CompanyCategoryID, CompanyID, CategoryID
In SQL, I normally will apply a simple join with group concatentation to get a row that looks like this:
CompanyID, Name, Categories
1, Dummy Company, Photographer;Videographer
I am trying to figure out how to best pull this information into a Company object in Java that contains references to another Category object. In my view, I'm not pulling the CategoryID or the CompanyCategoryID, but I will need those if I delete a category from a company, since it's in a separate table.
My question is would it be better to execute several SQL statements back to back? In other words:
SELECT * FROM company WHERE CompanyID=1; SELECT * FROM category WHERE CompanyID=1;
And then in Java combine them into a Company object with a List of Category objects, or should I let the database do the joining and just include a lot of extra information in my view?
SELECT * from company_view
CompanyID, Name, CompanyCategoryIDs, CategoryIDs, Categories
1, Dummy Company, 4;6, 2;3, Photographer;Videographer
My problem with the later is that it's going to quickly become problematic to keep straight, while I'm worried about performance with the former. For a single company, it's not going to be a big deal, but 2000-4000 companies could be loaded at any one time.
I really like the object oriented approach I'm taking to dealing with my database tables, but I'm not sure how best to deal with views.
Which would be more efficient?
I am creating an application in Spring JDBC and I have some questions regarding how to keep the object graphs and the database in correct state. If you have a car object with a list of parts. If you remove a part from the car then you need to save this into the database using a update operation in the car repository. Do you then have to find all the parts belonging to the car, then remove whatever part from the parts table? It means that I need to do find operations before updates?
I suppose it depends on the design of your database.
Given cars and parts, I would have something like
table cars: car_id, name
table parts: part_id, description
table installed_parts: car_id, part_id
A Cars object would have a List of Parts, which are drawn from the information in installed_parts.
When car.removePart(part) is invoked, the installed_part where car_id == Car.car_id and part_id = Part.part_id is removed.