iam software engineer (since few months ready study) , work develop large scalable web application. firm programming work , makes database behind it. defined data , relations between them didn't give hard database structure should use.
now first (internal) things visable. looked in database structure behind ans saw (in opinion) weirds.
for users created table users contains stuff id, email , password. near created user_meta table contains id, key , value.
when have user with:
- userid
- password
- name
- lastname
- address
- phone
the id, email , password stored in user table. other information rows created in user_meta table. means in case there 4 rows created 1 user (in our case more 20 rows each user) structure user every object should saved in database.
i learned create table contains data necessary user. in logic should 1 table 7 fields...
extra information:
- our software build on laravel framework (on advice)
- our software uses mysql database
questions:
- is normal way create database large systems or that, becouse never see in study or other projects in live.
- is best or bad practice?
- in opinion bad performance. when user count grows, true? or can done performance high (becouse not whole record needs selected ?(in our case expect @ least 100.000 users @ end of 2017 wil grow faster , faster when our project passes. there material chance grow far above 1.000.000 users in few years)
- i think reason why "objects" can changed easy in opinion allways posible add fields table , should never delete fields (also not when posible structure of database), opinion in right?
sorry when questions "noob questions" me first big project in live miss experience try manage project professionally. discuss wednesday in meeting. on way want prepare self bit in theme.
in opinion bad performance. when user count grows, true?
no.
there small difference in insert/update cost not dependent on volume of data accumulated. retrieval cost full record higher reduced partial record. @ end of day, performance differences negligible long record still resolved in single round trip db (unlike lot of trivial orm implementations).
the biggest impact functional. no effort add, say, attribute title eav table, normalized table may knocked offline while table stresteched accomodate wider records (or rows migrated). otoh can't enforce constraint @ database tier every customer must have email address.
is best or bad practice
of neither. although not documenting design decisions bad practice.
far above 1.000.000 users in few years
a million records not lot (unless database design bad).
Comments
Post a Comment