Въпрос за база данни

Здравейте. Пиша едно приложение на Ruby on rails(езика не е важен). И стигнах до това как да структурирам базата данни и по точно таблицата/таблиците за user/profile. Двоумя се точно как да ги структурирам. Като гледам имам 2 варианта.

1-ви вариант е да създам една голяма таблица с всички полета за узър, емайл, парола, токен за промяна на паролата, пол, местоположение, описание и т.н

2-ри вариант е да отделя основната информация в таблица user, а останалата като пол, описание, местоположение, в друга таблица profile.

Интересува ме, кой от тези 2 варианта е най-добър откъм performance. По мое мнение 2-рия вариант ще е най-добър откъм структуриране на данните и подреденост, но не съм много запознат с базата данни. Затова се обръщам към вас за мнение.

Във момента таблицата user изглежда така:

t.string "email"
t.string "password_digest"
t.datetime "created_at"
t.datetime "updated_at"
t.string "auth_token"
t.string "password_reset_token"
t.datetime "password_reset_sent_at

Поздрави,
Георги.

Re: Въпрос за база данни

няма смисъл да ги отделяш, освен ако за някое от тях няма да пазиш повече от 1 стойност. примерно за updated_at - ако искаш да следиш всички ъпдейти, можеш да го изведеш в отделна таблица. освен това едно ID няма да ти е излишно.

местоположението вече трябва да е в отделна таблица, но не го виждам в горния списък - примерно, таблица с държавите, таблица с градовете, вързана към държавите, таблица за профила с адрес, вързан към градовете, и в профила и друга информация.

ако кажеш по-конкретно каква друга информация искаш да сложиш, ще мога да помогна, а ако искаш, просто потърси в нета за нормализация на бази данни

Re: Въпрос за база данни

Благодря за отговора. Rails си слага тези полета автоматично created_at и update_at за да могат да се следят записите кога са създадени и кога са промени. За 2-рата таблица ще има user_id което ще го създам с асоциирането на двете таблици. В момента просто се чудя, кой от двато варианта да избера. Тази информация, която съм е дал е примерна. Полетата, ще са доста повече може би 15-20+ за това ме интересува дали една таблица или две различни(една с основна инф и друга с допълнителната)

Поздрави,
Георги

Re: Въпрос за база данни

това ти казвам - зависи от допълнителните полета - може и повече от 2 таблици да са

Re: Въпрос за база данни

Ясно. Значи отпада 1-вия варинат. Интересуваше ме ако е изведена информацията в повече таблици дали ще попречи на бързото изпълнение на заявките към тях.

Поздрави,
Георги.

Re: Въпрос за база данни

georgi_asgr каза:

Ясно. Значи отпада 1-вия варинат. Интересуваше ме ако е изведена информацията в повече таблици дали ще попречи на бързото изпълнение на заявките към тях.

Поздрави,
Георги.

Увеличете...

Зависи от заявките - ако булшинството ти от куерита селектират по username, което е масовия случай, значи втория вариант, но ако имаш сайт за запознанства и на home page вадиш различни сортировки по пол/vip статус/години и т.н. може и да не е оптимален. Дори и да са в една таблица, ако е индексирана добре ще вървят бързо заявките. (пак много зависи от синтаксиса на заявката, броя на записите в конкретната таблица, куери кеш на сървъра и т.н.)

Re: Въпрос за база данни

Това ме интересуваше. Видях в едно подобно приложение, че подобна гимнастика е направена по 2-рия вариант. Ще поразгледам още малко, но мисля и аз да се спра на 2-рия вариант. Благодаря и на двамата за носоките.

Поздрави,
Георги.

Re: Въпрос за база данни

ако не разбираш от оптимизация на бази данни, пусни тук нещата да помогнем, щото ако това оплескаш, после ще е мъка със сайта...

Тръгнах да пиша това, ама съм натиснал ентер без да искам - "Благодаря" се казва с бутончето с везната в горната дясна част на съответното мнение

Re: Въпрос за база данни

В крайна сметка използваш руби - базата данни ще ти е най-малкия проблем в случая, така че няма какво да го мислиш.

Re: Въпрос за база данни

Не така, колега Ако си направи калпава база данни, след това може да му се разгони фамилията и като програмиране, и като скорост на изпълнение на заявките...

Re: Въпрос за база данни

@mlazarov Да с active records е по-малка вероятноста да объркам нещата, но винаги е има тая възможност

@KOBRETI и да се объркат нещата с Active Records на Rails са бързо поправими нещата.

П.П опитах се да дам репутация, но в тоя момент ми спря интернета и нещо се оплексаха нещата. Защо не свети в зелено дадох му "I approve"?

Re: Въпрос за база данни

Прочети малко за "нормализация на база данни".

Според правилата ако имаш отношение 1:1 слагаш в една таблица.

Re: Въпрос за база данни

За репутацията - в началото изписва само сиво, после ще почне да свети зелено и червено, ама не знам точно какви са критериите.

Относно нормализацията, дето все ѝ виках оптимизация, потърси за 3NF и докарай нещата дотам. Има и 4-та и 5-та нормална форма, но в повечето случаи 3-та е достатъчна.

Re: Въпрос за база данни

Поразтърсих се малко и намерих едно интересно четиво на български за 3NF нормализация. Прилагам ЛИНК, за да послужи на някои занапред.

Поздрави,
Георги.

Re: Въпрос за база данни

виж сега какво мога да ти кажа от опит.
хубаво е да правиш нормализация, но според мен е по добре да имаш по малко JOIN-ове защото това бави, особенно като имаш order, group, limit и тн.

с течение на времето се научих да правя следната процедура.

1. правя си дизайн на базата със съответните номрализации
2. генерирам си 200-300-400 хиляди записа
3. тествам за колко време се изпълняват заявките (rails предполагам има profiler) гледам кои са бавни
4. ако има бавни заявки гледам как да ги оправя точка 1. (ако трябва премахвам нормализацията)

чак тогава пускам на лайв.

п.с. AR няма да те оптимизира заявките, най много да ти ги натовари

Здраве

=============
//едит
пак погледнах сега казуса и според мен отговорът е зависи какви ще са полетата на профила и какви заявки ще имаш към тази таблица. то и в документа ти го пише, че се прави денормализация за оптимизация

Re: Въпрос за база данни

Да rails има profiler, но не съм стигнал до етап да го използвам . Ще се възползвам от съвети ти и май ще го карам по твоята процедура.

Поздрави,
Георги.