 | |
#11
 
| |||
| |||
|
Re: Normalization question -
04-18-2007
, 06:22 PM
|
On Apr 16, 5:51 pm, "amygdala" <nore... (AT) noreply (DOT) com> wrote: "Ed Prochak" <edproc... (AT) gmail (DOT) com> schreef in berichtnews:1176746698.530701.83320 (AT) d57g2000hsg (DOT) googlegroups.com... [] 4) And I like the suggestion of using the email address as a key; it has validation and verification. I don't like the idea that throughout the site I would have to address user profiles as: http://www.somesite.com/getProfile?e...ress (DOT) com But, come to think of it, I could use username to serve that purpose of course. What's wrong with it? You might only need it for the inital login. What's wrong with using email as an identifier you mean? If so, let's say I was user X who wants to visit the profile of user Y: I don't want user X to know what the email address of user Y is. And since I'm building a site for which you don't need to be logged in to view ones profile, spamming issues come to mind here also. As I said, I was thinking it is only a login ID, so only the owner would need to know it. Thereafter your have a session ID transmitted back and forth. As far as accessing other profiles, that seems to be a new requirement. It wasn't mentioned in your original post. |
fact it doesn't have to be that obvious.
I have put all pretty much every attribute in one table now (except for
images, because a user is going to be able to have multiple images on their
profiles), but for making addressing profiles easy I _am_ going to use an
incrementing ID as PK.
Cheers.
#12
| |||
| |||
|
|
* top posting fixed * "Last Boy Scout" <BadBill (AT) whitehouse (DOT) gov> schreef in bericht news:FaBUh.1190$7n.877 (AT) newsfe12 (DOT) lga... amygdala wrote: Hi, Not too experienced yet when it comes to database normalization. And right now I'm working on a project in which I would like to have user profiles: My first impulse was to create a User table, a Person table and a Person_profile table The User table would just have the basics for a user to access in the system: - id // unique id - username - password - email // needed for registration verification - active // is user allowed to login? The Person table would have extended info about that person: - id // unique id - user_id // foreign key User.id - gender - firstname - lastname - birthdate - phone - etc.. The Person_profile table would have stuff like: - id // unique id - person_id // foreign key Person.id - image - url - description - active // is user allowed to have a profile - etc.. This all seemed logic from a perspective that things should be clarifying and well structured. Also I'm not to thrilled about having too many columns in one table (possible performance issues?) But the more I think about it the more I get the feeling that this approach is unnecessary, because all the information so far still belongs to only one user. And from browsing a little through some recent threads in this group I also got the impression that the id's in each table is overkill too. What are some of your views on this structure? Insights are much appreciated. Cheers. If you use an ID number as they key, one problem can be looking for duplicates as you enter the data. This is a problem if the key is a completely incremented field. Thanks for your insights. I hear you. I would have used UNIQUE KEY `email` (`email`) and UNIQUE KEY `username` (`username`) though. But using email as primary key is probably better yeah. |
to address userprofiles throughout the site. And I didn't like the idea of
having emailadresses put in querystrings of the url to fetch a user profile.
#13
| |||
| |||
|
|
"Ed Prochak" <edprochak (AT) gmail (DOT) com> schreef in bericht news:1176909206.728129.95710 (AT) l77g2000hsb (DOT) googlegroups.com... On Apr 16, 5:51 pm, "amygdala" <nore... (AT) noreply (DOT) com> wrote: "Ed Prochak" <edproc... (AT) gmail (DOT) com> schreef in berichtnews:1176746698.530701.83320 (AT) d57g2000hsg (DOT) googlegroups.com... [] 4) And I like the suggestion of using the email address as a key; it has validation and verification. I don't like the idea that throughout the site I would have to address user profiles as: http://www.somesite.com/getProfile?e...ress (DOT) com But, come to think of it, I could use username to serve that purpose of course. What's wrong with it? You might only need it for the inital login. What's wrong with using email as an identifier you mean? If so, let's say I was user X who wants to visit the profile of user Y: I don't want user X to know what the email address of user Y is. And since I'm building a site for which you don't need to be logged in to view ones profile, spamming issues come to mind here also. As I said, I was thinking it is only a login ID, so only the owner would need to know it. Thereafter your have a session ID transmitted back and forth. As far as accessing other profiles, that seems to be a new requirement. It wasn't mentioned in your original post. You're right, my bad. I guess I was thinking it would be obvious, when in fact it doesn't have to be that obvious. I have put all pretty much every attribute in one table now (except for images, because a user is going to be able to have multiple images on their profiles), but for making addressing profiles easy I _am_ going to use an incrementing ID as PK. Cheers. Another method is to leave the field set to null for inactive, and put |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.