fikiwan Posted July 24, 2013 Share Posted July 24, 2013 hello I thinking about wht is the best create many or just litle field in table a database : ex: I want create this : ---------------------------------------------------------------------------------------------------------------------------- | ID_U | firsname | lastName | email | biograp | comment | status_res | activatio | aim | jabber | ---------------------------------------------------------------------------------------------------------------------------- | 1 | fekke1 | laldjajdd | e@d.dcom | ndndn | blalalalal | a,ama | ,,,,,,,,, |....... | kakdd | 2 | dekj4 | jdhkhjdh | d@d.dcom |kskksk |blalalalal | a,amnka |,,,,,,,,,,, | ,,,,,,,,| ksjdhd |------------------------------------------------------------------------------------------------------------------------------ you can look in above I create 10 field in my table , Now I thingking only will make 4 field look ex below : -------------------------------------------------------- | ID_MG | ID_UMG | KEY_MG | VALUE_KEY | -------------------------------------------------------- | 1 | 1 | firsname | blalalalal | | 2 | 1 | lastName | blalalalal | | 3 | 1 | email | blalalalal | | 4 | 1 | biograp | blalalalal | | 5 | 1 | comment | blalalalal | | 6 | 1 | status_res | blalalalal | | 7 | 1 | activatio | blalalalal | | 8 | 1 | aim | blalalalal | | 9 | 1 | jabber | blalalalal | --------------------------------------------------------- you could look both example at above , first table with many field and second just with 4 field , now , in two way that, what the best way for on use database .. thanks for explain to me regards Link to comment Share on other sites More sharing options...
niche Posted July 25, 2013 Share Posted July 25, 2013 (edited) The fewer fields (they're called columns in sql) the better. How you use them is up to you. It looks like you're creating a table to store user info. There are many possible columns you could create. As I said earlier, the fewer the better. Edited July 25, 2013 by niche Link to comment Share on other sites More sharing options...
fikiwan Posted July 25, 2013 Author Share Posted July 25, 2013 thanks ... so the best way is second field .. thanks .. for your help .. Link to comment Share on other sites More sharing options...
niche Posted July 25, 2013 Share Posted July 25, 2013 Yes, provided you only need four columns. Link to comment Share on other sites More sharing options...
Don E Posted July 25, 2013 Share Posted July 25, 2013 (edited) For what it's worth, I give you thumbs up for typing all that to illustrate your question/post. Edited July 25, 2013 by Don E Link to comment Share on other sites More sharing options...
justsomeguy Posted July 25, 2013 Share Posted July 25, 2013 I've seen data stored both ways. It's probably going to be a little faster if you store all of the data for a single user in one row rather than one field per row. It's also going to require more storage if you store one field per row, because you have to duplicate the field name for each user. But it's going to be more extendable or flexible if you have the second structure. One issue with having the second structure though is that you lose some of the power of indexes and constraints on the database. With the second structure you can't have the database enforce something like the name or email can't be blank, and you can't index certain fields (like email) to make them faster for lookups on that field. You can make both ID_MG and ID_UMG as a joint primary key in the second structure, and that will help some for speed, but the second structure is generally going to be slower. It's up to you whether you want to optimize your application to be more easily modified and extended, or faster. I typically use the first structure for things like users where the fields don't change much. If the list of fields might change frequently (which happens when you're storing certain objects in a database), then you might want to use the second structure for those objects. It would make sense to mix the two in a single application, where the objects whose fields don't change often use the first structure, and other things use the second. Link to comment Share on other sites More sharing options...
fikiwan Posted July 25, 2013 Author Share Posted July 25, 2013 I've seen data stored both ways. It's probably going to be a little faster if you store all of the data for a single user in one row rather than one field per row. It's also going to require more storage if you store one field per row, because you have to duplicate the field name for each user. But it's going to be more extendable or flexible if you have the second structure. One issue with having the second structure though is that you lose some of the power of indexes and constraints on the database. With the second structure you can't have the database enforce something like the name or email can't be blank, and you can't index certain fields (like email) to make them faster for lookups on that field. You can make both ID_MG and ID_UMG as a joint primary key in the second structure, and that will help some for speed, but the second structure is generally going to be slower. It's up to you whether you want to optimize your application to be more easily modified and extended, or faster. I typically use the first structure for things like users where the fields don't change much. If the list of fields might change frequently (which happens when you're storing certain objects in a database), then you might want to use the second structure for those objects. It would make sense to mix the two in a single application, where the objects whose fields don't change often use the first structure, and other things use the second. thanks for the explanation . I do thingking all day about it, so that i back here ..(ask more) if I want store many data user then KEY_MG will have many duplicate ,ya i thingking it not good for many data dummy in a field.. and i can give index in a field fewer field may be good but valid field it is the best.. thanks much once again .. regards Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now