The tables are for users to access different places
The design as below:
user table:
<user>
userid
username
place (the row define access rights)
place table:
<place>
placeid
placename
floor
My thoughts:
three places and placeid are 001,002,003
one user and userid is 001 to aceess these three places
<user>
userid username place
001 john 001,002,003
<place>
placeid placename floor
001 A 1
002 B 2
003 C 3
004 D 4
My question is,
in "user" table, the attribute "place" contains many placeids,
and separate by a comma, this design is fine or bad ?
It needs to separate the place values from "user" table ?
Using a comma delimited list to do a many to many relationship is bad design. You should use an intermediate table instead:
<user>
userid
username
<place>
placeid
placename
floor
<accessrights>
userid
placeid
Instead of putting "1,2,3" in user.place for userid 001, then, you put three rows in accessrights, all with userid 001 and one with each placeid.
That's not a good idea. Make a separate table to store the relationship:
<users-places>
userid placeid
1 1
1 2
1 3
Indexing your approach would not be straight forward - although possible.
Use the name "users-places" as it implies what 2 tables it relates. Change the name if you significantly store more information about this relationship - ie, you start adding columns to this new table.
Also, name your tables in the plural form. Singular is reserved for class names. Tables are thought of as collections.
Thank you all,
I modified my design as below, is it fine ?
<user>
userid username groupid
1 john 1
<group>
groupid groupname
1 admin
2 general
3 special
<group_manage>
groupno groupid placeid
1 1 1
2 1 2
3 1 3
4 1 4
5 2 1
6 2 2
7 2 3
<place>
placeid placename floor
1 A 1
2 B 2
3 C 3
4 D 4
Related
I have control dashboard where multiple tables are listed with query
And in dashboard I can switch it to one table from ALLData to User1Table... and vice versa.
When there is only one table chosed I can easily manipulate data. However, I am struggling with updating rows when ALLData(all tables) are listed in dashboard. I can update it checking each table. I was wondering is there any better way to update it.
Tables have no DR. All tables have same column names.
//ALLData
SELECT * FROM users1
UNION ALL
SELECT * FROM users2...
user1
id name tel status
1 Bob 911 1
user2
id name tel status
3 Anna 11 0
3 Jack 12 1
//ALLData in dashboard
id name tel status
1 Bob 911 1
3 Anna 11 0
3 Jack 12 1
I can use id and status as PK
I have a requirement to store user's proper location & send them newsletters as per them, I would like to understand the best way to store them as I have been finding it challenging to retrieve it after storing.
First of all, the address that needs to be stored is like:-
Country1-City1-SocietyName1-AnyMoreSmallLocation1-...so on.
So, now what I have done so far...
Table 1...
PID Place Parent
1 Country1 0
2 Country2 0
3 City1 1
4 City2 1
5 City3 2
6 Society1 3
n so on
Then
User table where I am keeping location with UID
UID Name PID
1. John 6
2. Sam 7
But at the get call of user location it needs to be like this...society name, city, country. which seems not good as per current design..please suggest.
If each user has only one adress, consider having only one table :
UID Name Country City etc.
But if there is multiple adresses per user, 2 tables (User and Adress):
UID Name
AdresseID UID Country City etc.
I'm building a e-Commerce platform (PHP + MySQL) and I want to add a attribute (feature) to products, the ability to specify (enable/disable) the selling status for specific city.
Here are simplified tables:
cities
id name
==========
1 Roma
2 Berlin
3 Paris
4 London
products
id name cities
==================
1 TV 1,2,4
2 Phone 1,3,4
3 Book 1,2,3,4
4 Guitar 3
In this simple example is easy to query (using FIND_IN_SET or LIKE) to check the availability of product for specific city.
This is OK for 4 city in this example or even 100 cities but will be practical for a large number of cities and for very large number of products?
For better "performance" or better database design should I add another table to table to JOIN in query (productid, cityid, status) ?
availability
id productid cityid status
=============================
1 1 1 1
2 1 2 1
3 1 4 1
4 2 1 1
5 2 3 1
6 2 4 1
7 3 1 1
8 3 2 1
9 3 3 1
10 3 4 1
11 4 3 1
For better "performance" or better database design should I add
another table
YES definitely you should create another table to hold that information likewise you posted rather storing in , separated list which is against Normalization concept. Also, there is no way you can gain better performance when you try to JOIN and find out the details pf products available in which cities.
At any point in time if you want to get back a comma separated list like 1,2,4 of values then you can do a GROUP BY productid and use GROUP_CONCAT(cityid) to get the same.
Maybe it's because I don't understand how to search for the right verbiage, but I'm having difficulty understanding how to attach multiple users to a table with multiple columns.
Here is what I'm attempting to do:
table name: user
user_id user_name
1 abc
2 xyz
3 pqr
4 new
table2 name : brackets
id user_id bracket_name
1 4,2 bracket_1
2 4,3,1 bracket_2
3 2,1 bracket_3
4 3,4,2 bracket_4
-- OR --
table name: user
user_id user_name brackets_id
1 abc 2,3
2 xyz 1,3,4
3 pqr 2,4
4 new 1,2,4
table2 name : brackets
brackets_id user_id bracket_name
1 4,2 bracket_1
2 4,3,1 bracket_2
3 2,1 bracket_3
4 3,4,2 bracket_4
I'm using nodejs and sequalize as my ORM and understand enough to read, write, delete and update to these tables, but when it comes to organizing my data, I'm completely lost!
Is it possible to add an array to MYSQL with the user ID's or the brackets that the user is allowed to access? The bracket are generated by a user and then they can invite their friends to join a bracket. Users can join multiple brackets and join other brackets as users.
Any guidance would be very helpful!
I think a Junction Table would simplify this for you: http://en.wikipedia.org/wiki/Junction_table
It would look something like:
table name: user
user_id user_name
1 abc
2 xyz
3 pqr
4 new
table2 name : brackets
brackets_id bracket_name
1 bracket_1
2 bracket_2
3 bracket_3
4 bracket_4
table3 your junction table:
user_id brackets_id
1 2
1 3
2 1
2 3
2 4
etc.etc.
Supoose I have the following:
tbl_options
===========
id name
1 experience
2 languages
3 hourly_rate
tbl_option_attributes
=====================
id option_id name value
1 1 beginner 1
2 1 advanced 2
3 2 english 1
4 2 french 2
5 2 spanish 3
6 3 £10 p/h 10
7 3 £20 p/h 20
tbl_user_options
================
user_id option_id value
1 1 2
1 2 1
1 2 2
1 2 3
1 3 20
In the above example tbl_user_options stores option data for the user. We can store multiple entries for some options.
Now I wish to extend this, i.e. for "languages" I want the user to be able to specify their proficiency in a language (basic/intermediate/advanced). There will also be other fields that will have extended attributes.
So my question is, can these extended attributes be stored in the same table (tbl_user_options) or do I need to create more tables? Obviously if I put in a field "language_proficiency" it won't apply to the other fields. But this way I only have one user options table to manage. What do you think?
EDIT: This is what I propose
tbl_user_options
================
user_id option_id value lang_prof
1 1 2 null
1 2 1 2
1 2 2 3
1 2 3 3
1 3 20 null
My gut instinct would be to split the User/Language/Proficiency relationship out into its own tables. Even if you kept it in the same table with your other options, you'd need to write special code to handle the language case, so you might as well use a new table structure.
Unless your data model is in constant flux, I would rather have tbl_languages and tabl_user_languages tables to store those types of data:
tbl_languages
================
lang_id name
1 English
2 French
3 Spanish
tbl_user_languages
================
user_id lang_id proficiency hourly_rate
1 1 1 20
1 2 2 10
2 2 1 15
2 2 3 20
3 3 2 10
Designing a system that is "too generic" is a Turing tarpit trap for a relational SQL database. A document-based database is better suited to arbitrary key-value stores.
Excepting certain optimisations, your database model should match your domain model as closely as possible to minimise the object-relational impedance mismatch.
This design lets you display a sensible table of user language proficiencies and hourly rates with only two inner joins:
SELECT
ul.user_id,
u.name,
l.name,
ul.proficiency,
ul.hourly_rate
FROM tbl_user_languages ul
INNER JOIN tbl_languages l
ON l.lang_id = ul.lang_id
INNER JOIN tbl_users u
ON u.user_id = ul.user_id
ORDER BY
l.name, u.hour
Optionally you can split out a list of language proficiencies into a tbl_profiencies table, where 1 == Beginner, 2 == Advanced, 3 == Expert and join it onto tbl_user_languages.
i'm thinking it's a mistake to put "languages" as an option. while reading your text it seems to me that english is an option, and it might have an attribute from option_attributes.