ડેટાબેઝ ડિઝાઇન માં બનાવવામાં આવેલ સામાન્ય ભૂલો

તમે ડેટાબેઝ સાથે કામ કરી રહ્યા છો કે જે સેંકડો રેકોર્ડ્સ અથવા લાખો રેકોર્ડ ધરાવે છે, યોગ્ય ડેટાબેઝ ડિઝાઇન હંમેશાં મહત્વપૂર્ણ છે. માત્ર તે જ માહિતી પુનઃપ્રાપ્ત કરી શકશે નહીં, તે ભવિષ્યમાં ડેટાબેઝ વિસ્તરણને સરળ બનાવશે. કમનસીબે, ભવિષ્યમાં વસ્તુઓને મુશ્કેલ બનાવી શકે તેવા કેટલાક ફાંસોમાં આવવું સહેલું છે.

ડેટાબેઝને સામાન્ય કરવાના વિષય પર લખેલા સમગ્ર પુસ્તકો છે, પરંતુ જો તમે આ સામાન્ય ભૂલોને ટાળી શકો છો, તો તમે સારા ડેટાબેઝ ડિઝાઇનના યોગ્ય ટ્રેક પર જશો.

ડેટાબેઝ ભૂલ # 1: કોષ્ટકમાં પુનરાવર્તન ક્ષેત્ર

સારી ડેટાબેઝ ડિઝાઇન માટે અંગૂઠાનો મૂળભૂત નિયમ પુનરાવર્તન ડેટાને ઓળખવાનો અને તે પોતાના ટેબલમાં તે પુનરાવર્તિત કૉલમને મૂકવાનો છે. કોષ્ટકમાં ક્ષેત્રોને પુનરાવર્તન કરવું તે સ્પ્રેડશીટ્સના વિશ્વમાંથી આવે છે તે માટે સામાન્ય છે, પરંતુ જ્યારે સ્પ્રેડશીટ્સ ડિઝાઇન દ્વારા ફ્લેટ હોય છે, ડેટાબેઝ સંબંધ હોવા જોઈએ. તે 2D થી 3D પર જવા જેવું છે

સદભાગ્યે, પુનરાવર્તિત ક્ષેત્રો સામાન્ય રીતે શોધવામાં સરળ છે. આ ટેબલ પર નજારો જુઓ:

ઓર્ડર આઈડી ઉત્પાદન 1 ઉત્પાદન 2 ઉત્પાદન 3
1 ટેડી રીંછ જેલી બીન
2 જેલી બીન

ઑર્ડર જ્યારે ચાર પ્રોડક્ટ્સ ધરાવે છે ત્યારે શું થાય છે? ત્રણથી વધુ ઉત્પાદનોને ટેકો આપવા માટે અમને બીજા ક્ષેત્રને ટેબલ પર ઉમેરવાની જરૂર છે. અને જો આપણે કોષ્ટકની આસપાસ એક ક્લાયન્ટ એપ્લિકેશન બનાવી છે, જે અમને ઇનપુટ માહિતી માટે મદદ કરે છે, તો અમને નવા ઉત્પાદન ક્ષેત્ર સાથે તેને બદલવાની જરૂર પડી શકે છે. અને અમે ક્રમમાં Jellybeans સાથે તમામ ઓર્ડર કેવી રીતે શોધી શકું? અમે ટેબલમાં પ્રત્યેક પ્રોડક્ટ ફીલ્ડને SQL સ્ટેટમેંટ સાથે ક્વેરી કરવા માટે ફરજ પાડવામાં આવશે જે આના જેવી લાગે: SELECT * FROM PRODUCTS WHERE PRODUCT1 = 'Jelly Beans' અથવા Product2 = 'Jelly Beans' અથવા Product3 = 'Jelly Beans'

એક જ કોષ્ટક ધરાવતી જગ્યાએ, જે બધી માહિતી એકસાથે ભેગા કરે છે, આપણી પાસે ત્રણ કોષ્ટકો હોવો જોઈએ જે દરેક પાસે એક અલગ માહિતી ધરાવે છે. આ ઉદાહરણમાં, અમે ઑર્ડર્સ ટેબલ વિશે માહિતી, પ્રોડક્ટ્સ ટેબલ, અમારા તમામ ઉત્પાદનો અને પ્રોડક્ટ ઑર્ડર્સ ટેબ્લેટ સાથેની માહિતી સાથે પ્રસ્તુત કરવા માંગીએ છીએ જે ઉત્પાદનોને ક્રમમાં જોડે છે.

ઓર્ડર આઈડી ગ્રાહક ઓળખાણ પત્ર ઓર્ડર તારીખ કુલ
1 7 1/24/17 19.99
2 9 1/25/17 24.99
ProductID ઉત્પાદન ગણક
1 ટેડી રીંછ 1
2 જેલી બીન 100
ProductOrderID ProductID ઓર્ડર આઈડી
101 1 1
102 2 1

નોંધ લો કે કેવી રીતે દરેક કોષ્ટકનું પોતાનું અનન્ય ID ક્ષેત્ર છે. આ પ્રાથમિક કી છે અમે બીજા કોષ્ટકમાં વિદેશી કી તરીકે પ્રાથમિક કી મૂલ્યનો ઉપયોગ કરીને કોષ્ટકોને લિંક કરીએ છીએ. પ્રાથમિક કીઓ અને વિદેશી કીઓ વિશે વધુ વાંચો.

ડેટાબેઝ ભૂલ # 2: કોષ્ટકમાં કોષ્ટકને એમ્બેડ કરવું

આ બીજી એક સામાન્ય ભૂલ છે, પરંતુ તે હંમેશાં પુનરાવર્તિત ક્ષેત્રો જેટલી જ ઉભી થતી નથી. ડેટાબેઝને ડિઝાઇન કરતી વખતે, તમે ખાતરી કરો કે કોષ્ટકમાંના તમામ ડેટા પોતે સંબંધિત છે તે જુદું જુદું જુદું પાડવું તે બાળકની રમત જેવું છે જો તમારી પાસે કેળા, એક સ્ટ્રોબેરી, આલૂ અને ટેલિવિઝન સેટ છે, તો ટેલિવિઝન સેટ કદાચ બીજી જગ્યાએ છે.

એ જ રેખાઓ સાથે, જો તમારી પાસે લોકોનું વેચાણનું કોષ્ટક છે, તો તે કોષ્ટકમાંની બધી માહિતી વિશિષ્ટપણે તે સેલ્સ વ્યક્તિને સંબંધિત હોવી જોઈએ. કોઈપણ વધારાની માહિતી કે જે તે સેલ્સ વ્યક્તિ માટે અનન્ય નથી તે તમારા ડેટાબેઝમાં બીજે ક્યાંક હોઈ શકે છે.

સેલ્સઆઇડી પ્રથમ છેલ્લા સરનામું ફોન નંબર ઓફિસ ઓફિસનમ્બર
1 સેમ ઇલિયટ 118 મુખ્ય સ્ટ્રીટ, ઓસ્ટિન, ટેક્સાસ (215) 555-5858 ઑસ્ટિન ડાઉનટાઉન (212) 421-2412
2 એલિસ સ્મિથ 504 સેકન્ડ સ્ટ્રીટ, ન્યૂ યોર્ક, એનવાય (211) 122-1821 ન્યૂ યોર્ક (પૂર્વ) (211) 855-4541
3 જૉ પૅરિશ 428 એકર સેન્ટ, ઓસ્ટિન, ટેક્સાસ (215) 545-5545 ઑસ્ટિન ડાઉનટાઉન (212) 421-2412

જ્યારે આ કોષ્ટક કદાચ વ્યક્તિગત વેચાણકર્તા સાથે સંબંધિત છે તેવું દેખાશે, તે વાસ્તવમાં કોષ્ટકની અંદર કોષ્ટક ધરાવે છે. નોંધ લો કે "ઑસ્ટિન ડાઉનટાઉન" સાથે ઓફિસ અને ઓફિસનમ્બર કેવી રીતે પુનરાવર્તન થાય છે. જો કોઈ ઓફિસ ફોન નંબરમાં ફેરફાર થાય તો શું? તમને માહિતીના એક ભાગને બદલવા માટે સંપૂર્ણ ડેટાના ડેટાને અપડેટ કરવાની જરૂર છે, જે ક્યારેય સારી વાત નથી. આ ક્ષેત્રો તેમના પોતાના ટેબલ પર ખસેડવામાં આવશે.

સેલ્સઆઇડી પ્રથમ છેલ્લા સરનામું ફોન નંબર OfficeID
1 સેમ ઇલિયટ 118 મુખ્ય સ્ટ્રીટ, ઓસ્ટિન, ટેક્સાસ (215) 555-5858 1
2 એલિસ સ્મિથ 504 સેકન્ડ સ્ટ્રીટ, ન્યૂ યોર્ક, એનવાય (211) 122-1821 2
3 જૉ પૅરિશ 428 એકર સેન્ટ, ઓસ્ટિન, ટેક્સાસ (215) 545-5545 1
OfficeID ઓફિસ ઓફિસનમ્બર
1 ઑસ્ટિન ડાઉનટાઉન (212) 421-2412
2 ન્યૂ યોર્ક (પૂર્વ) (211) 855-4541

આ પ્રકારની ડિઝાઇન તમને ઓફિસ ટેબલમાં વધારાની માહિતી ઉમેરવાની ક્ષમતા આપે છે, વેચાણની ટેબલમાં ક્લટરના દુઃસ્વપ્ન વગર. કલ્પના કરો કે શેરી સરનામું, શહેર, રાજ્ય અને પિન કોડનો ટ્રેક રાખવા માટે કેટલું કાર્ય હશે જો બધી માહિતી વેચાણની ટેબલમાં હતી!

ડેટાબેઝ ભૂલ # 3: એક ફિલ્ડમાં માહિતીના બે અથવા વધુ પિસીસને મુકીને

વેચાણકર્તા કોષ્ટકમાં ઓફિસની માહિતીને એમ્બેડ કરવું તે ડેટાબેઝમાં માત્ર એક જ સમસ્યા નથી. સરનામાં ક્ષેત્રમાં ત્રણ ભાગની માહિતી શામેલ છે: શેરી સરનામું, શહેર અને રાજ્ય. ડેટાબેઝમાંના દરેક ક્ષેત્રમાં ફક્ત એક જ ભાગની માહિતી હોવી જોઈએ. જ્યારે તમારી પાસે એકલ ક્ષેત્રમાં બહુવિધ માહિતી હોય, ત્યારે માહિતી માટે ડેટાબેઝને પૂછવા માટે તે વધુ મુશ્કેલ બની શકે છે.

ઉદાહરણ તરીકે, જો આપણે ઑસ્ટિનના તમામ વેચાણકર્તાઓ પર એક ક્વેરી ચલાવવા માગીએ તો શું? અમે સરનામાં ફિલ્ડમાં શોધવાની જરૂર છે, જે માત્ર બિનકાર્યક્ષમ નથી, પરંતુ ખરાબ માહિતી પરત કરી શકે છે. બધા પછી, શું થાય છે જો કોઈ પોર્ટલેન્ડ, ઑરેગોનમાં ઑસ્ટિનની શેરીમાં રહેતા હોય?

કોષ્ટક શું આના જેવુ જોઈએ તે અહીં છે:

સેલ્સઆઇડી પ્રથમ છેલ્લા સરનામું 1 સરનામું 2 શહેર રાજ્ય ઝિપ ફોન
1 સેમ ઇલિયટ 118 મુખ્ય સ્ટ્રીટ ઓસ્ટિન TX 78720 2155555858
2 એલિસ સ્મિથ 504 સેકન્ડ સ્ટ ન્યુ યોર્ક NY 10022 2111221821
3 જૉ પૅરિશ 428 એકર સેન્ટ એપ્પટ 304 ઓસ્ટિન TX 78716 2155455545

નોંધ અહીં કેટલીક બાબતો છે. પ્રથમ, "Address1" અને "Address2" પુનરાવર્તિત ક્ષેત્રોની ભૂલ હેઠળ આવે તેમ લાગશે.

જો કે, આ કિસ્સામાં તેઓ માહિતીના અલગ અલગ ટુકડાઓનો ઉલ્લેખ કરી રહ્યા છે જે ડેટાના પુનરાવર્તન જૂથને બદલે તેના પોતાના ટેબલમાં જવાની બદલે સીધા વેચાણકર્તાને સંબંધિત છે.

ઉપરાંત, ટાળવા માટે બોનસની ભૂલ તરીકે, નોંધ લો કે ફોન નંબર માટેની ફોર્મેટિંગ કોષ્ટકમાંથી છીનવી લેવામાં આવી છે. જ્યારે શક્ય હોય ત્યારે તમારે ક્ષેત્રોના બંધારણને સંગ્રહિત કરવાનું ટાળવું જોઈએ. ફોન નંબરોના કિસ્સામાં, ઘણા લોકો ફોન નંબર લખે છે: 215-555-5858 અથવા (215) 555-5858 આનાથી સેલ્સ વ્યક્તિને તેમના ફોન નંબરથી અથવા સમાન વિસ્તાર કોડના લોકોની શોધને વધુ મુશ્કેલ બનાવવા માટે શોધ કરી શકશે.

ડેટાબેઝ ભૂલ # 4: યોગ્ય પ્રાથમિક કીનો ઉપયોગ કરતા નથી

મોટા ભાગના કિસ્સાઓમાં, આપ આપમેળે વધતી સંખ્યા અથવા તમારી પ્રાથમિક કી માટે કોઈ અન્ય જનરેટેડ નંબર અથવા આલ્ફાન્યૂમેરિકનો ઉપયોગ કરવા માગો છો. પ્રાથમિક કી માટે કોઈ વાસ્તવિક માહિતીનો ઉપયોગ કરવાનું ટાળવું જોઈએ, જો તે એવું લાગે કે તે સારી ઓળખકર્તા બનાવશે.

ઉદાહરણ તરીકે, અમારી પાસે દરેકની પાસે અમારી પોતાની વ્યક્તિગત સુરક્ષા નંબર છે, તેથી કર્મચારી ડેટાબેઝ માટેના સામાજિક સુરક્ષા નંબરનો ઉપયોગ કરીને એક સારો વિચાર આવી શકે છે. પરંતુ દુર્લભ હોવા છતાં, સામાજિક સુરક્ષા નંબર બદલવા માટે પણ શક્ય છે, અને અમે ક્યારેય અમારી પ્રાથમિક ચાવી બદલવા માંગીએ છીએ નહીં.

અને કી માહિતી તરીકે વાસ્તવિક માહિતીનો ઉપયોગ કરવામાં સમસ્યા છે. તે બદલી શકે છે

ડેટાબેઝ ભૂલ # 5: નામકરણ કન્વેન્શનનો ઉપયોગ કરતા નથી

આ તમારા ડેટાબેઝને ડીઝાઇન કરવાનું પ્રારંભ કરતી વખતે મોટા સોદો થઈ શકશે નહીં, પરંતુ જ્યારે તમે માહિતી મેળવવા માટે ડેટાબેઝ સામે લેખિત પ્રશ્નો પૂછ્યા, ત્યારે નામકરણ સંમેલન રાખવામાં તમને મદદ મળશે કારણ કે તમે ક્ષેત્ર નામો યાદ રાખશો.

જસ્ટ કૉપિ કરો કે તે પ્રક્રિયા કેટલો વધુ મુશ્કેલ હશે જો નામો એક નામ અને First_name, Last_name બીજા કોષ્ટકમાં FirstName, LastName તરીકે સ્ટોર કરવામાં આવ્યા હતા.

બે સૌથી લોકપ્રિય નામકરણ સંમેલનો ક્ષેત્રના દરેક શબ્દના પ્રથમ અક્ષરને મૂકાત કરે છે અથવા અન્ડરસ્કૉરનો ઉપયોગ કરીને શબ્દોને અલગ કરે છે. તમે કેટલાક વિકાસકર્તાઓને પ્રથમ શબ્દ સિવાય દરેક શબ્દના પ્રથમ અક્ષરને મોટું કરી શકો છો: FirstName, lastName.

તમે એકલ ટેબલ નામો અથવા બહુવચન ટેબલ નામોનો ઉપયોગ કરવાનું નક્કી કરવા પણ ઇચ્છશો. શું તે ઓર્ડર ટેબલ અથવા ઓર્ડર્સ કોષ્ટક છે? શું તે ગ્રાહક ટેબલ અથવા ગ્રાહકો ટેબલ છે? ફરીથી, તમે કોઈ ઓર્ડર કોષ્ટક અને ગ્રાહક કોષ્ટક સાથે અટવાઇ નથી માંગતા.

નામકરણનું સંમેલન જે તમે પસંદ કરો છો તે મહત્વનું નથી કારણ કે નામકરણની સંમેલનને પસંદ કરીને ચોંટી રહેવું.

ડેટાબેઝ ભૂલ # 6: અયોગ્ય અનુક્રમણિકા

અનુક્રમણિકા અધિકાર મેળવવાની સૌથી સખત વસ્તુઓ પૈકી એક છે, ખાસ કરીને ડેટાબેઝ ડિઝાઇનમાં તે નવા માટે. બધી પ્રાથમિક કીઓ અને વિદેશી કીઓ અનુક્રમિત થવી જોઈએ. ઇન્ડેક્સ વિના આ લિંક કોષ્ટકો એકસાથે છે, તમે તમારા ડેટાબેઝમાંથી ખૂબ નબળો દેખાવ જોશો.

પરંતુ જે ઘણી વખત ચૂકી જાય છે તે અન્ય ક્ષેત્રો છે. આ "WHERE" ફીલ્ડ્સ છે જો તમે વારંવાર WHERE ખંડમાં કોઈ ફીલ્ડનો ઉપયોગ કરીને તમારી શોધને સાંકડી કરવા જતા હોવ, તો તમે તે ક્ષેત્ર પર ઇન્ડેક્સ મૂકવા વિશે વિચારો છો. જો કે, તમે કોષ્ટકનું વધુ પડતું ઇન્ડેક્સ માંગતા નથી, જે પ્રદર્શનને નુકસાન પણ કરી શકે છે.

કેવી રીતે નક્કી કરવા? આ ડેટાબેઝ ડિઝાઇનની કળાનો એક ભાગ છે. તમારે કોષ્ટકમાં કેટલા સૂચકાંકો મૂકવો જોઈએ તેની કોઈ મર્યાદા નથી. મુખ્યત્વે, તમે કોઈપણ ક્ષેત્રને ઇન્ડેક્સ કરવા માંગો છો કે જે વારંવાર WHERE ખંડમાં વપરાય છે. તમારા ડેટાબેઝને યોગ્ય રીતે અનુક્રમિત કરવા વિશે વધુ વાંચો