Jump to content

about field dabatabe ...


fikiwan
 Share

Recommended Posts

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

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 by niche
Link to comment
Share on other sites

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

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...