In a microservice architechture with each microserice having it's own database, what is the recommended way of creating a one-to-many relationship between two microservices?
In my case I have two tables:
products
CREATE TABLE IF NOT EXISTS product.products (
"id" UUID DEFAULT uuid_generate_v4(),
...
)
collections
CREATE TABLE IF NOT EXISTS collection.collections (
"id" UUID DEFAULT uuid_generate_v4(),
...
)
What is recomennded between the following options?
a) products has field "collection" UUID
b) collections has field "products" UUID[]
c) both
Or is there another answer which better suits my use case, and if so, why?
Related
I am trying to create a table in my database using Visual Studio.
I've got a table for my Products (like in online shop) and then I have a table for Orders, which should store all products that user has ordered. The problem is that I am not sure which datatype I should use when designing the database to store an array of products in my Orders table. This is what the Orders table should look like
You should create Products and Orders table with relationship between them.
Your Orders table should have Id column as well (which is PrimaryKey)
Then you should create Products table, that keeps all the information about products and additionaly OrderId which should be used as Foreign Key to Orders table.
Please look at that link:
https://msdn.microsoft.com/en-us/library/ms189049.aspx
It's also worth of checking:
One To One, One To Many, Many To Many relations in SQLServer to have better understanding and design your data store properly.
In your case you need ProductsOrders table, Many To Many relationship.
In Relational database, you can create a relationship between 2 tables.
The relationship can be
1 to 1 (1 Product - 1 Order)
1 to Many (1 Product - 'n' Order)
Many to Many (n product - 'n' Order)
Based on your scenario, You can choose any of the relationship listed above. While querying from the database, you can easily operate over each order/Product.
Cake newb here.
I have two tables. Users and Events. An user can subscribe to Multiple events.
What is the best way to implement this?
Do I have to create another table and link them or is there any other better approach.
If I do create a new table, how do i link them in cake model?
As said by jQuery.PHP.Magento.com you should use HABTM relationship but the name of the third table should be events_users because the table names should be in alphabetical order.
From the doc:
Table names are in alphabetical order by convention. It is possible to
define a custom table name in association definition.
You should use HABTM relationship.
Reason
See users will subscribe to Multiple events and
One event have multiple users subscribed for.
So this is two way relationship. Therefore you need following tables
users : To store user's data,
events : To store user's data,
events_users : To store Which user joined Which event and Vice versa(Events with n number of users)
So users_events will have 2 fields user_id , event_id , both are foreign keys and here you dont need primary key in HABTM relationship.
I have three tables in my table named "users", "role" and "user_meta". And i want to use these tables in my model named "User.php" to save the data. But the problem is that if i associate the other two tables with "users" table then cakephp asked for the plural form of the table. It means i have defined the table name as "role" and "user_meta" then cakephp asking for "roles" and "user_meta".
Now problem is that i cannot change my table name, I have use these table names.
Can anyone help me out to How to save data in the other tables?
Thanks,
Sunil Jindal
The idea is to have one model per table.
What you want to use is Model::$useTable to change the table of the models.
I'm trying to get my way with DynamoDB and NoSQL.
What is the best (right?) approach for modeling a student table and class tables with respect to the fact that I need to have a student-is-in-class relationship.
I'm taking into account that there is no second-index available in DynamoDB.
The model needs to answer the following questions:
Which students are in a specific class?
Which classes a student take?
Thanks
A very simple suggestion (without range keys) would be to have two tables: One per query type. This is not unusual in NoSQL databases.
In your case we'd have:
A table Student with attribute StudentId as (hash type) primary key. Each item might then have an attribute named Attends, the value of which was a list of Ids on classes.
A table Class with attribute ClassId as (hash type) primary key. Each item might then have an attribute named AttendedBy, the value of which was a list of Ids on students.
Performing your queries would be simple. Updating the database with one "attends"-relationship between a student and a class requires two separate writes, one to each table.
Another design would have one table Attends with a hash and range primary key. Each record would represent the attendance of one student to one class. The hash attribute could be the Id of the class and the range key could be the Id of the student. Supplementary data on the class and the student would reside in other tables, then.
To join two Amazon DynamoDB tables
The following example maps two Hive tables to data stored in Amazon DynamoDB. It then calls a join across those two tables. The join is computed on the cluster and returned. The join does not take place in Amazon DynamoDB. This example returns a list of customers and their purchases for customers that have placed more than two orders.
CREATE EXTERNAL TABLE hive_purchases(customerId bigint, total_cost double, items_purchased array<String>)
STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler'
TBLPROPERTIES ("dynamodb.table.name" = "Purchases",
"dynamodb.column.mapping" = "customerId:CustomerId,total_cost:Cost,items_purchased:Items");
CREATE EXTERNAL TABLE hive_customers(customerId bigint, customerName string, customerAddress array<String>)
STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler' TBLPROPERTIES ("dynamodb.table.name" = "Customers",
"dynamodb.column.mapping" = "customerId:CustomerId,customerName:Name,customerAddress:Address");
Select c.customerId, c.customerName, count(*) as count from hive_customers c
JOIN hive_purchases p ON c.customerId=p.customerId
GROUP BY c.customerId, c.customerName HAVING count > 2;
I need to make 100 or so tables. I have tables called PartStatsXXX and the tables to be made will all be called PartReviewXXX (they pair up with each other in a 1:n relationship).
Is it efficient to create one big table to store all product (product and part being the same term from a business perspective) reviews? Someone mentioned making a relationship from PartStatsXXX to PartsReview (one large table) with the value of XXX as part of the primary key from PartStatsXXX.
XXX is the name of the part type (eg battery, wiring loom, etc). So this will be varchar. Should I make a composite key? The part type wouldn't change names (though some part names can have multiple names depending on culture), but it's not really a candidate ID. It was then mentioned I could get several views for what I need depending on the value of XXX.
I hope this makes sense. What would be the best approach?
Thanks
Multi-table PartStatsXXX is a bad idea: hard to code properly or with a framework, harder to maintain, nightmare to query...
Use two tables: PartStats and PartsReview, with approriate keys and indexes for performance.
It is more efficient to create tables based on what you want to store in each one. You do not need 100 tables for 100 products. you need 1 table for all products.
So for your needs I would create 2 tables:
products
========
id INT
name VARCHAR
product_reviews
===============
id INT
product_id INT (foreign key to products.id)
rating INT (example column)
Unless you are storing different types of data for each product's reviews (i.e., each table has a different set of columns), using a different table per product will be creating an unnecessary nightmare.
As a general rule, you never want to have more than one table with the same set of columns. As already suggested, one table with a "product_id" column is the way to go.
If you want to save yourself some pain in a quick-and-dirty way, use two tables.
CREATE TABLE PartStats (
...,
PartType VARCHAR(255),
...
);
CreateTable PartReview (
...
PartType VARCHAR(255),
...
);
and then join them up via
SELECT ...
FROM PartStats ps JOIN PartReview pr
ON ps.PartType = pr.PartType;
This gets you out from having hundreds of tables, but sets you up for a different problem: Redundant data (PartType) that can get out of sync. A typo in a PartType can yield an orphaned review.
The solution here, assuming that you can have more than one PartStats entry for a given PartType, is to add a third table to the sole older of PartType names.
CREATE TABLE PartType (
ID INT ...,
PartType VARCHAR(255),
PRIMARY KEY (ID)
);
and arrange for PartStats and PartReview to use the ID of a PartType. For example,
CREATE TABLE PartStats (
...,
PartType_ID INT REFERENCES PartType(ID),
...
);
CREATE TABLE PartReviews (
...
PartType_ID INT REFERENCES PartType(ID),
...
);
This will prevent your making a PartStats or a PartReview for a non-existent PartType.
If query performance becomes an issue, adding secondary indexes on PartType_ID will help.
I can recommend you a couple of not bad books on database design (several months ago I decided to improve my database design skills so I took a look at several different books and chose these two):
1) Pro SQL Server 2008 Relational Database Design and Implementation (c) Louis Davidson
2) Relational database design clearly explain (c) Jan Harrington
Good luck!