|
|
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
есть таблица users, там хранятся ид, пароли, емайлы и прочие параметры при авторизации в эту же таблицу заносится время входа, страница посещаемая пользователем, ип адрес, последний визит и т.д., по сути это куча запросов типа UPDATE так вот, возможно есть смысл вынести все эти UPDATE-параметры в отдельную таблицу session и там с ними работать, какие это даст плюсы/минусы/преимущества, даст ли прирост по скорости, уменьшению нагрузки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2010, 13:00 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
опятья , создание дополнительных таблиц врядли даст выигрыш в скорости заполнения данными. Но весьма "расширит кругозор" обработки данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2010, 13:26 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
по сути все прекрасно хранится в одной таблице, но из всех данных часть статические и не меняются, а другая часть меняется с каждым запросом пользователя к серверу, вот я и подумал может есть хитрое приспособление для оптимизации данного случая :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2010, 13:36 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
Есть такое понятие -- нормализация. Нормализация это разделение данных на несколько связанных таблиц. Наличие большого количества узких таблиц является характерной особенностью нормализованной базы данных. Наличие небольшого количества широких таблиц является признаком ненормализованной базы данных. Нормализация улучшает производительность. При возможности использования полезных индексов оптимизатор запросов является действенным средством в выборе быстрых, эффективных соединений между таблицами. примечание : таблица называется узкой если в ней мало столбцов. если много столбцев то таблица широкая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2010, 14:07 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
мда по поводу предыдущего опуса о нормализации первые полтора предложение еще куда не шло, но потом вообще-то пурга ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2010, 14:52 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
nosov Есть такое понятие -- нормализация. Нормализация это разделение данных на несколько связанных таблиц. Наличие большого количества узких таблиц является характерной особенностью нормализованной базы данных. Наличие небольшого количества широких таблиц является признаком ненормализованной базы данных. Нормализация улучшает производительность. При возможности использования полезных индексов оптимизатор запросов является действенным средством в выборе быстрых, эффективных соединений между таблицами. примечание : таблица называется узкой если в ней мало столбцов. если много столбцев то таблица широкая. нормализуй плиз таблицу useridnameemailpasslast_time_visit1adminadmin@mail.ruqwerty123456798 меняется только поле last_time_visit при каждом обращении пользователя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2010, 12:48 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
опятья нормализуй плиз таблицу useridnameemailpasslast_time_visit1adminadmin@mail.ruqwerty123456798 меняется только поле last_time_visit при каждом обращении пользователя а теперь слегка поменяем требования к системе - требуется вести историю логинов ;) В общем случае подобного рода логирование не должно находиться в таблицах с сущностями - оно должно выноситься в отдельное место и там и храниться. Иначе таблицы быстро превращаются в помойку. И это еще без учета влияния на производительность, т.к. запись БД затягивается в память целиком (разве что индекс создан под интересующий запрос) соответственно увеличивая количество логических чтений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2010, 13:23 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
авторменяется только поле last_time_visit при каждом обращении пользователятолько 2 поля должно быть в таблице - user_id - last_time_visit остальные данные практически не меняются поэтому их выносим в справочник (имхо) примечание : справочник это тоже таблица. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2010, 14:53 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
историю логинов хранить не требуется, не надо менять изначальные задачи плиз nosov , тоесть в дальнейшем мы заменяем один просто запрос к таблице SELECT * FROM user WHERE id=1 на запрос к нескольким таблицам SELECT * FROM user_name, user_email, user_pass, user_last_time_visit WHERE id=1 и получаем какое то преимущество в производительности? индекс в таблице один уникальный - userid ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2010, 16:50 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
2 автор один из шагов нормализации -- разделение широких таблиц на несколько связанных узких таблиц. надо так создать таблицы чтобы данные нигде не повторялись повторятся могут и должны только ай-ди. этим мы экономим место на жестком диске связывание таблиц позволяет вытянуть нужные данные из нескольких таблиц одним селектом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2010, 17:59 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
StalkerSа теперь слегка поменяем требования к системе - требуется вести историю логинов ;)Ведите. :) StalkerSВ общем случае подобного рода логирование не должно находиться в таблицах с сущностями - оно должно выноситься в отдельное место и там и храниться. Иначе таблицы быстро превращаются в помойку.[quot StalkerS]Вынести историю в отдельную таблицу - это конечно правильно. Но в тоже время затраты на могут быть и выше. [quot StalkerS]И это еще без учета влияния на производительность, т.к. запись БД затягивается в память целиком (разве что индекс создан под интересующий запрос) соответственно увеличивая количество логических чтений.На этот случай анализ должен быть проведен акк часто данные могут меняться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2010, 20:30 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
Блин, quot'ы местами перепутал капитально в предыдущем посте. Сорри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2010, 20:31 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
опятьяисторию логинов хранить не требуется, не надо менять изначальные задачи плиз nosov , тоесть в дальнейшем мы заменяем один просто запрос к таблице SELECT * FROM user WHERE id=1 на запрос к нескольким таблицам SELECT * FROM user_name, user_email, user_pass, user_last_time_visit WHERE id=1 и получаем какое то преимущество в производительности? индекс в таблице один уникальный - useridНу так и флаг вам в руки: 1) Создайте таблицу под пользователей, например, UserList. 2) В исходной таблице останутся столбцы (userid, last_time_visit), уже говорили тут про это выше. Все остальные столбцы вынести в UserList + туда же userid, по которому и будешь джойнить. ЗЫ. А вообще не стОит учет пользователей вести "самопально". Сервер для этих целей лучше приспособлен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2010, 20:44 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
Senya_LА вообще не стОит учет пользователей вести "самопально". Сервер для этих целей лучше приспособлен.уважаемый Сеня -- мы тут пыхтим велосипед изобретаем а вы молчали. Помогите чайникам укажите плз как эта фича в BOL называется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2010, 09:16 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
nosov2 автор один из шагов нормализации -- разделение широких таблиц на несколько связанных узких таблиц. надо так создать таблицы чтобы данные нигде не повторялись повторятся могут и должны только ай-ди. этим мы экономим место на жестком диске связывание таблиц позволяет вытянуть нужные данные из нескольких таблиц одним селектом. Скорей всего, приведение таблиц к нормальным формам осуществляется на основе выявления зависимомстей между атрибутами посредством декмпозиции ("разделения") таблиц не зависимо от "ширины" или "узости". Экономия места на диске, скорей всего, является последней целью устранения избыточности (физическая проблема). На первом все же, возможно, ожидаются логические проблемы контроля избыточности. Например, нашли ошибку и в случае избыточности, не достаточно исправитть ее в одном месте. Нужно просмативать все дубли. Кроме того могут быть и др аномалии из-за того что БД не находится, например в 3-ей нормальной форме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2010, 11:25 |
|
||
|
какие преимущества у множества таблиц?
|
|||
|---|---|---|---|
|
#18+
vadiminfoприведение таблиц к нормальным формам осуществляется на основе выявления зависимомстей между атрибутами посредством декмпозиции ("разделения") таблиц не зависимо от "ширины" или "узости". Экономия места на диске, скорей всего, является последней целью устранения избыточности (физическая проблема). На первом все же, возможно, ожидаются логические проблемы контроля избыточности. Например, нашли ошибку и в случае избыточности, не достаточно исправитть ее в одном месте. Нужно просмативать все дубли. Кроме того могут быть и др аномалии из-за того что БД не находится, например в 3-ей нормальной форме.+1 Аномалии могут быть и тогда, когда отношение также не находится во 2НФ... :-) Основная цель нормализации - это устранение избыточности данных. Наличие избыточности ведет к аномалиям в операциях запоминания (INSERT, UPDATE, DELETE). К.Дейт (1980)Реляционная модель базы данных (РМБД) - это совокупность изменяемых во времени нормализованных отношений различных степеней.То есть РМБД использует только нормализованные отношения - то есть находящиеся, как минимум, в 1НФ (в первой нормальной форме). Ширина таблиц (отношений) тут совершенно не причем - всё определяется зависимостями реляционной модели данных. P.S. А реляционная модель данных - это лишь еще одна попытка описания реального мира... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2010, 21:29 |
|
||
|
|
start [/forum/topic.php?fid=32&tid=1542679]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
154ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 465ms |
| 0 / 0 |
