tag:blogger.com,1999:blog-29597047.post5254578607382648497..comments2023-06-02T11:57:59.987+03:00Comments on shady's: Why would you need a Gender table in your DB??Shady M. Najibhttp://www.blogger.com/profile/15517845851043368287noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-29597047.post-58548498619515557602010-01-17T23:13:37.188+02:002010-01-17T23:13:37.188+02:00I kinda agree.. Yet, you forgot that on most enter...I kinda agree.. Yet, you forgot that on most enterprise applications, such changes always happen.. <br /><br />Also concerning SQL-joins & performance, etc; there're ways to optimize either through view, procedures, etc (SQL engines are smart enough to compile similar stuff to run faster) or even through hardware :)<br /><br />Thanks for taking the time to read it :)Shady M. Najibhttps://www.blogger.com/profile/15517845851043368287noreply@blogger.comtag:blogger.com,1999:blog-29597047.post-7662412961390747582010-01-16T14:16:46.104+02:002010-01-16T14:16:46.104+02:00Agree with M.AtiaAgree with M.AtiaMohamed Gamal El-Dinhttps://www.blogger.com/profile/09385298097882580455noreply@blogger.comtag:blogger.com,1999:blog-29597047.post-46219354351174416452010-01-16T01:08:09.556+02:002010-01-16T01:08:09.556+02:00Well, I find this approach very broad, and I think...Well, I find this approach very broad, and I think for small problems like this one enum would do it. If I used for each Data field like this a new table, like gender, martial status ..., it will be a mess in the SQL statements writing, Joins just need more concentration, but in more complicated situations I prefer your approach, as you said it will give you the chance to edit afterward some of Mohamed Atiahttps://www.blogger.com/profile/08341411556660497200noreply@blogger.com