Here I am creating a view
CREATE VIEW customerusage
AS
SELECT group_concat(customername SEPARATOR ' ||| '),
customerlocation,
customerid,
product
FROM customer AS c
INNER JOIN product AS p ON (c.product_id = c.product_id)
GROUP BY product_id
This table is to be updated everyday, if it is done in every minute is too fine. How can I update it. Is any option other then view also fine to do.
You need to make your view updatable. See http://dev.mysql.com/doc/refman/5.6/en/view-updatability.html
In summary:
A view is updatable if there is a one-to-one relationship between the rows in the view and the rows in the base table that are going to be updated.
A view is insertable if it is updatable and the columns present in the base table but not named in the view have default values.
I think, the expression group_concat(customername SEPARATOR ' ||| ') will break the one-to-one relationship. I.e. this expression could prevent your view to be updatable.
The expression GROUP BY product_id will definitely break a one-to-one relationship between the view and the base table.
The other way around, when you update/insert on the base table, it will be reflected on the view depending one-to-one relationship. If there is such a relationship, the view will use a MERGE algorithm and modifications in the base table will be reflected in the view. If there is no such a one-to-one relationship the used algorithm will be TEMPLATE, that means, a temporary table will be created for the view. See http://dev.mysql.com/doc/refman/5.0/en/view-algorithms.html for view algorithms.
Related
Hi, I'm designing a item catalog using MySQL and Squalize ORM (NodeJS).
Suppose I have a product list with different attributes based on its category (attributes_id in this case).
I would like to get a product by using a JOIN statement with an appropriate attribute table. The design should be scalable as we will have more than a hundred attribute tables.
Roughly the statement will look like this:
JOIN
if ( product.attributes_id == 1 ) 'attributes_car'
elseif ( product.attributes_id == 2 ) 'attributes_food'
BUT the the number of elseif cases will grow more than a hundred later.
So the question is how to design attributes_id? Is it a good idea to make it a foreign key to the database metadata (like INFORMATION_SCHEMA) to point to another table? Should I introduce another table to manage such relationship?
One of option is a Dynamic SQL but I don't think it is a good idea because the ifelse cases should grow.
Or should I give up designing a query and just implement such logic on NodeJS side using ORM?
Thank you!
One solution would be to create an additional table that stores attribute_id and table_name.
Create table attibute_tablename(
attribute_id int(11),
table_name varchar(25),
PRIMARY KEY (attribute_id, table_name)
)
You can also add a foreign key to the product table if you want.
Then you only need an insert to this table for every new item added
I am designing a database for my app. In which I want to do mapping between multiple tables. Now situation is like There is one user table. User can have generate multiple orders. So I was thinking if I can put json obejct of order_id in a column in order table. Or I can create a user_id column in order table & repeat user_id for same user. So which is a better way of doing it?
PS: What is the standard way of doing it?
You should just have user_id in your order table, then make queries like
select * from orders where user_id = *some_user_id*
A user can place multiple orders which in turn can have multiple line items. Each line item can have n quantity of a specific product. So when product comes in picture, then it becomes many to many relationship between user and product because a user can place order for many products and a product can be ordered by many users. So my suggestion is -
Create a User table with UserID
Create a PurchaseOrder table with OrderID, UserID and LineItemID
Create a LineItem table with OrderID, ProductID and LineItemID
Create a SKU table with ProductID
A user can place multiple orders.
Based on this you should maintain three different tables as given below:
User (user_id,...)
Order (order_id,...)
UserOrder (user_id,order_id,...)
Only the primary keys in the above tables are focused
Storing comma separated list or json object will worsen the design. And this is strongly discouraged.
EDIT:
As #NevilleK suggested, the above design is typically used for many-to-many relationships. For one-to-many relationship you can create a foreign key constraint in orders table where user_id should refer to the user_id in the User table.
But still you can adopt the above design for one-to-many relationship since many-to-many qualifies for one-to-many too.
The best way is to have different table for your
User table - which hosts the user information
Transaction table - which will have order_id against each user_id.
Transaction table will carry all the transaction details with user_id. If you create a JSON object, how will you map the USER to the transaction. So at the time of retrieving the json information you will have to map it to the user table anyway. I suggest you the use the above said method, which will help you maintain and scale your application much easily.
I have a web application which allows users to join multiple groups.
I have a 'users' table which stores details about the users (id, email, password, etc.) and a 'groups' table which stores details about the available groups (id, name, owner of group).
I have been researching the best way to store group memberships (i.e. which users are in which group, bearing in mind they can be members of multiple) - however I am still not sure what the most efficient solution would be.
Would you recommend I:-
Create a second table called 'group_memberships' and store the user's ID along with the corresponding group ID?
Store an array alongside the group particulars in the 'groups' table with the user IDs of its members?
Approach this task a different way?
The DBMS I am using is phpMyAdmin.
I would advise you to go with option 1; where you have a Mapping Table for linking Users & Groups.
The Users Table will have PK on User_ID.
The Groups table will have PK on Group_ID.
The Mapping table will have User_ID(FK) and Group_ID(FK).
Now you should have PK on these two columns together.
This will ensure you don't have duplicate entries.
What you're describing is called a many-to-many relationship in database terms. A user can belong to multiple groups, and groups have more than one user (or else they wouldn't be "groups"!).
Your first idea, the group_memberships table, is the accepted best way to model this relationship. Although you'll want to name it users_groups or something similar to reflect the fact it relates or associates those two tables. At its most basic, this association table needs three columns:
ID (primary key)
user_id (foreign key)
group_id (foreign key)
By JOINing to this table ON either user_id or group_id, you can find the related records from either side of the relationship. And you can do it right from a SQL query, without any additional code like you'd need if you stored an array.
I would definitely go with option 1 - creating the junction table 'group_memberships' - I have used this approach many times without problems. Don't forget to add an Index on the new table 'group_memberships' for columns: 'groupID' and 'userID'.
Option 2 is not scalable for a large amount of data, especially if groups have a lot of users.
UPDATE:
For info on Indexes, here is a good (and short) blog: https://blog.viaduct.io/mysql-indexes-primer/.
The first option is a right choice. Actually it is a materialized view for both user table and group table.
Just think materialized view as a extra table or a redundant data structure that denormalizes the user properties and group properties together for quick search.
Since if we do not have the view, when we query a group id to list all its users, we have to filter millions of users to check if he/she is in the certain group. It is a performance nightmare!
Mysql has tools to build this view very efficiently. You may build secondary index on this view columns for quick search, say, group id, group name, user id, user name or something else you hope to search with.
good luck :-)
I have 2 tables.
First table is called professions, and those are indexed by ID. So each profession now has a unique ID associated with it.
My second table is called contacts, and in there I have a profession field that right now only hold the ID that a certain profession is associated with.
My problem is that what if I have a contact that has more than one profession associated with it.
What would be the best way to query the table and ways to store the professions of a contact. I didn't want to do is create a field to just store a 0 or 1 int for each profession I have. The reason is because I want to dynamically grow the professions table and have the numbers reflect any dynamic changes on my site when I query.
You have a many-to-many relationship. To implement that in MySQL you should use a linking table. So professions and contacts should have an id in each table, but no foreign keys, and you create a new table called profession_contact_links or something, containing its own id, and profession_id and contact_id, which are both foreign keys to the respective tables. Then you can have many contacts linked with each profession, and many professions linked with each contact. To connect the two main tables together in a select you will need two joins, and what they are will depend on what exactly you want to select.
The standard solution to this modelling issue is called a link table.
Basically it is a table that contains the ids of the two tables that are linked, so you would have a link table with to columns and a primary key that is both of those columns:
(profession_id, contact_id)
or the other order... doesn't matter that much, but the order can affect performance, the key you will be searching on most often is the one you want first.
You then use either SELECT ... IN (...) or SELECT ... JOIN ... to query the data that you are after.
Depending on what you want and how you want to find it, i'd suggest rlike or in
SELECT ... FROM <table> WHERE <column name> RLIKE "^id1|id2|id3$"
This will find any cell that contains any of those three terms
or use
SELECT ... FROM <table> Where <column name> IN ('id1','id2','id3')
this will find any cell that is equals to one of those three.
I have an access table that has its own information as well as a subdatasheet that was linked to it using child/master fields. For each record in the table, there is one record in the subdatasheet. I was wondering if one can give me code for a query that would put all of this into one table.
If you are certain of the one-to-one relationship, then you can simply JOIN on the Foreign key relationship between the "Master" and "Child" tables:
SELECT m.PKID, m.MasterField1, m.MasterField2, c.ChildField1, c.ChildField2
FROM ChildTable AS c INNER JOIN MasterTable AS m ON c.ClientID = m.ClientID;
If you are really intending to merge these into a new table, then open the Access Query Editor, select SQL View from the View menu, and paste the above sample into the SQL view. Then swap your table names, and column names for those above (adding m.MasterField3, 4, . . . c.ChildField3, 4, etc . . .).
Then select Make Table Query from the Query type menu. Type a unique name for your new table, and Run the query.