Im building web app which include user authentification, so every user will have profile with personal data. Data will be stored in db, but due to their privacy users can choose which of their informations will be displayed to public visitors. Let say someone want to hide his phone number from others, so he will go to account setings and choose "hide" option. But I cant figure out how to make it with db and rest of app.
Any guidance or reference will be helpfull. Thanks
Make your table look like something like this. This means that John and Laura have different privacy settings than Jane and sam.
+-------+------------+------------+--------+
| user | phone | address | hidden |
+-------+------------+------------+--------+
| john | 2025550165 | example 1 | 1 |
| jane | 2026118043 | example 2 | 0 |
| sam | 2026682607 | example 3 | 0 |
| laura | 2026688273 | example 4 | 1 |
+-------+------------+------------+--------+
To use this, the SQL would be something like: SELECT user, phone, address from table where hidden = 0
which would return only jane and sam.
Does this help at all?
You can create some table like user_settings where user can set what fields should not be visible to public
Related
I'm trying to create a system which keeps the user logged in (something like remember me checked). Ok I have a table like this:
// cookies
+---------+-------------------------+------------------+------------+------------+
| id | email | cookie | date_time | device |
+---------+-------------------------+------------------+------------+------------+
| int(11) | varchar(50) | varchar(128) | int(11) | |
+---------+-------------------------+------------------+------------+------------+
| 1 | jack_2009#gmail.com | ojer0f934mf2... | 1467204523 | |
| 2 | peter.zm#yahoo.com | ko4398f43043... | 1467205521 | |
| 3 | matrix_john23#gmail.com | 34fjkg3j438t... | 1467205601 | |
| 4 | peter.zm#yahoo.com | 0243hfd348i4... | 1467206039 | |
+---------+-------------------------+------------------+------------+------------+
As you see, this user peter.zm#yahoo.com have logged in by two different devices:
| 2 | peter.zm#yahoo.com | ko4398f43043... | 1467205521 | |
| 4 | peter.zm#yahoo.com | 0243hfd348i4... | 1467206039 | |
So email column isn't unique and each device has its own row.
My question: How can I fill device column?
Why do I need to determine devices? Because when an user removes his browser's cookies, then my website identifies him as a new user and creates a new row for him into table above. So after a while, there will be some redundant rows in the table.
For example: Imagine peter has just two devices (laptop, phone). And he have two rows into table above. Ok, he removes his browser's cookies and logs in. What happens? My website creates a new row into table above. Now peter has 3 rows into table above (while he has just two devices). So surely one of those three rows is redundant. That's why I need to detect devices to remove redundant rows.
How about with the User Agent string from their last interaction with your application?
As an additional defence-in-depth security measure, you could also validate that the user agent matches their previously used one for this device in order to mitigate session hijacking. Be aware that any browser or OS upgrades will invalidate the "remember-me" on that device though.
As a side note, you are better off keying on a unique ID rather than email address because that way it is much easier to update a user's email should you need to in future.
Use the web authn api or the credentials api
I am looking for some general information in regards to User Table Design.
I have an old table design for 'users', which I need to update but not breaking the entire site's structure.
Current Table Design
UserID | Email | FirstName | Last Name | ...
1 | a#a.com | John | Doe | ...
2 | b#b.com | Jane | Doe | ...
I need to be able to create "Primary" users, as well as "Assitant" users.
Now I believe I should have a few tables designed:
Users
Accounts
Users > Accounts - (Relationships & Permissions)
IE: of users > accounts
TableID | UserID | AccountID | PERM
1 | 1 | 1 | 001
So I guess my question is. Is there a better way to do this? Specifically if there is a current design being used?
Hope this makes sense. Any direction in this would be greatly appreciated.
Here's an example where you'd have a table for each group, plus a users table. You can filter the users by group using a JOIN. Personally I don't love this. If anyone else has a better suggestion, I'd like to hear it.
http://sqlfiddle.com/#!9/993dd/1
I have already asked here Query Logic SQL and didn't get a response(could be with the presentation of my data) I really hope someone can take a look at this and provide their input on how to get this done. would highly appreciate any help.
I have a sql table data that looks like
users table
id | name |
_______________
1 | John |
2 | Mary |
3 | Charles |
4 | Mike |
5 | Lucy |
6 | Debbie |
pairing table:
main_id | pair_id |
_____________________
1 | 2 |
1 | 3 |
2 | 4 |
2 | 5 |
3 | 6 |
3 | 1 |
when rendering output to user, my html table would look like this, using group_by groupconcat in sql.
main_name | paired_names
John | Mary, Charles
Mary | Mike, Lucy
Charles | Debbie, John
Now,the problem is during searching(wildcard search)
say the user will input "Charles"...
The output needs to be:
main_name | paired_names
John | Mary, Charles
Charles | Debbie, John
since its going to do a wildcard search in both columns in the pair table.
For now, what i do is i manipulate the result set from the database but this has pagination and been advised that it will affect system performance if i query all data then manipulate after.
I hope someone will be kind enough to provide their advice on how to get this done.
I can provide further details if needed.
Looking forward to hear from you.
Checks the fiddle
SELECT users.id,GROUP_CONCAT(pair_id) FROM (SELECT users.id,
users.name,pairing.main_id,pairing.pair_id
FROM users, pairing
WHERE pairing.main_id=users.id
) AS t1 JOIN users ON users.id=t1.id GROUP BY users.id;
OK, Last post on this subject (I hope). I've been trying to look into normalisation for tables in a website that I've been building and I have to be honest that I've struggled with it, however after my last post it seems that I may have finally grasped it and set my tables properly.
However, one question remains. If I create a table that is seemingly in 3rd normal form, is it acceptable to have areas of white space or empty cells if the data is relevant to that specific table? Let me give you an example:
On a news website I have an Authors_Table
+----+-----------+----------+-----------------+-------------------+---------+----------+---------+
| ID | FIRSTNAME | SURNAME | EMAIL | BIO ( REQUIRED ) | TWITTER | FACEBOOK | WEBSITE |
+----+-----------+----------+-----------------+-------------------+---------+----------+---------+
| 01 | Brian | Griffin | brian#gmail.com | About me... | URL | | URL |
| 02 | Meg | Griffin | meg#gmail.com | About me... | URL | | |
| 03 | Peter | Griffin | peter#gmail.com | About me... | | URL | URL |
| 04 | Glen | Quagmire | glen#gmail.com | About me... | URL | URL | |
+----+-----------+----------+-----------------+-------------------+---------+----------+---------+
This would be used on the article page to give a little details about who has written it, which is very common in newspapers and on modern blogs. Now the last 3 columns Facebook, Twitter, Website are obviously relevant to the Author & therefore to the PK (ID). As you know though, not everyone has either twitter or a wesbite or facebook so the content of these cells is rather flexible so obviously empty cells will occur in some cases.
It was suggested to do it another way so I produced:
Links
+----+-------------------+
| ID | TYPE |
+----+-------------------+
| 01 | Facebook |
| 02 | Twitter |
| 03 | Website |
+----+-------------------+
Author_Links
+----------+--------+------+
| AUTHOR | TYPE | LINK |
+----------+--------+------+
| 01 | 01 | URL |
| 01 | 02 | URL |
| 01 | 03 | URL |
| 02 | 02 | URL |
| 02 | 03 | URL |
| 03 | 01 | URL |
+----------+--------+------+
Now I understand the concept of this however isn't it just as "correct" to have and to use the original table. Updates can be made using a form & php to say:
$update_link_sql = "UPDATE authours SET facebook = ' NEW VALUE ' WHERE id = '$author_id'";
$update_link_res = mysqli_query($con, $update_links_sql);
As for me Authors_Table is correct.
| ID | FIRSTNAME | SURNAME | EMAIL | BIO ( REQUIRED ) | TWITTER | FACEBOOK | WEBSITE |
The only reason to have three tables:
Authors
| ID | FIRSTNAME | SURNAME | EMAIL | BIO ( REQUIRED ) |
Link_types
| ID | TYPE |
Author_links
| AUTHOR_ID | LINK_TYPE_ID | URL |
...is that your authors could have more than one link of specific type (for example two twitter accounts, btw, is it legal?)
If we suppose that any author can have no more than one account of each type - your version with single table is correct.
Either way is acceptable depending on functional requirements.
If you need to dynamically add more url types/fields to profile then use latter.
If there is ever going to be only 3 then former is better.
No need to over-engineer.
Yes, it's "correct" to store "optional" attributes as columns in the entity table. It's just when we have repeated values, e.g. multiple facebook pages for an author, for example, that we'd want to implement the child table. (We don't want to store "repeating" attributes in the entity table.)
As long as there's a restriction in the model, that an attribute will be limited to a single value (a single facebook page, a single twitter, etc.) those attributes can be stored in the entity table. We'd just use a NULL value to indicate that a value is not present.
One benefit of the separate table approach (outlined in your post) is that it would be "easier" to add a new "type" of URL. For example, if in the future we want to store a blogspot URL, or an instagram URL, instead of having to modify the entity table to add new columns, we can simply add rows to the "link_type" table and "author_link" table. That's the big benefit there.
I am developing a community site for high school students. I am trying to implement a like and unlike system using PHP. Heres what I have got :
A table named likes in MySQL with 3 columns namely app_id VARCHAR(32), user VARCHAR(12), dormant VARCHAR(6).
UNIQUE(app_id,user)
When a person likes a page on my site, a row is either inserted or updated in the likes table with dormant = false.
When a person unlikes a page, the row present is again updated with dormant = true. This is an alternative to deleting the row as it is a bit intensive for a speedy work of likes and unlikes.
I want to know, if I should go for deleting the row instead of updating it, when someone unlikes the page.
Dont Delete the row. Every data you can gather its a valuable data point.
I would say you should create a new record for every unlike also.
These data will be usefull to you in the future to figure out user behaviour.
Some ppl might like smth now and then unlike it , then like it again and so on.
Maybe in the future u would like to see why so many people who liked an item suddely unliked it then liked it again.
So i say gather as much data as you can.
Sounds like premature optimization. Don't do that.
Design your application as you want to use it /as it should work. When it gets busy, find out the bottlenecks and fix them.
If you want to design your application for scalability to the millions, consider using a different database engine / programming platform altogether.
Looks like you haven't record the number of user liked or unliked the pages. In this case, LIKES should be a many table and there should be another table called APPS (or any name you wish) to store pages:
**USER**
+---------+-------+-----+
| user_id | name | ....|
+---------+-------+-----+
| 1 | ... | ... |
+---------+-------+-----+
| 2 | ... | ... |
+---------+-------+-----+
**APPS**
+---------+-------+-----+
| app_id | name | ....|
+---------+-------+-----+
| 1 | ... | ... |
+---------+-------+-----+
| 2 | ... | ... |
+---------+-------+-----+
**LIKES**
+---------+-------+----------+----------+
| like_id |user_id| app_id | is_liked |
+---------+-------+----------+----------+
| 1 | 1 | 2 | 1 |
+---------+-------+----------+----------+
| 2 | 1 | 3 | 0 |
+---------+-------+----------+----------+
Where you can toggle if the user click like( is_liked = 1) or unlike( is_liked = 0) the page