|
|
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
Для работы фотогалереи создала следующие таблицы: fotodivide - id, name ------ таблица разделов subdivide - id, idFD(поле связи с fotodivide), name --------- таблица подразделов foto - id, idSD(поле связи с subdivide), dateUP, description, userId, dir(типа int), size(varchar), smallsize(varchar) ---- таблица фото users - id и т.д. ------ таблица пользователей tags - id, name ------- таблица тэгов fototag - idfoto, idtag --------- таблица связи тэгов с изображениями И вот, запрос на выборку фото, если пользователь выбрал подраздел, выглядел так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Затем решила нормализовать базу и начала с таблицы фото, в результате она разраслась еще на несколько: foto - id, idSD, dateUP, description, idUser sizes - id, name -------- таблица размеров фото fotosizes - idfoto, idsize ----- табилца связи фото и полного размера smallsizes fotosmallsize - тоже, но для урезанных изображений dirs - id, dir -------- таблица каталогов, в которых находятся фото fotodir - idfoto, dirid ------ таблица связей фото и каталогов Решила проверить скорость выполнения запроса на этой БД, запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. время выполнения первого запроса ~ 0,0063, второго ~ 0,015 Так вот вопрос: нужно ли делать нормализацию, если после нее скорость работы падает примерно в 2 раза? p.s. Код запросов приведены намеренно, вдруг дело в них, а не в структуре таблиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2013, 14:41 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
niranaтаблица размеров фото А какой смысл у этой таблицы? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2013, 14:44 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, хранение размеров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2013, 14:46 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
niranaхранение размеров Для чего? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2013, 14:50 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovniranaхранение размеров Для чего? для того, чтобы выводить фото в немного уменьшенном виде в правильных пропорциях, или вместо этого каждый раз вызывать функцию getimagesize? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2013, 14:55 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
niranaдля того, чтобы выводить фото в немного уменьшенном виде в правильных пропорциях, или вместо этого каждый раз вызывать функцию getimagesize? Пофиг. Зачем на размеры отдельная таблица? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2013, 15:40 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovПофиг. Зачем на размеры отдельная таблица? Потому что они повторяются, зачем хранить повторяющиеся значения. Вы бы более конкретно спрашивали сразу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2013, 15:47 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
nirana, Нормализация делается не для ускорения выборок - т.е. в общем-то в Вашем результате ничего удивительного нет. С другой стороны, осмысленность приведенной нормализации тоже сомнительна. Выделить sizes в отдельную таблицу еще можно, если у фото встречается лишь десяток стандартных размеров. Но зачем делать таблицу связей "многоие ко многим"? И все размеры, и "маленькие", и "большие", нужно, конечно, держать в одной таблице. Смысл же в выделении dirs вообще непонятен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2013, 11:33 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинНо зачем делать таблицу связей "многоие ко многим"? Не очень поняла, а как выглядит таблица связей "один к одному"? А про табилцу dirs скажу, что там очень часто повторяются данные, но от нее вообще, конечно, можно отказаться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2013, 23:04 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
> Смысл же в выделении dirs вообще непонятен. Смысл как раз понятен: конфигурируемая файловая структура. Но использовать ее следует по-другому: directory (id, parent_id, ...) photo (id, directiry_id, ...). Для размеров отдельная таблица не нужна. Классификация - никак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2013, 00:49 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
nirana. Не очень поняла, а как выглядит таблица связей "один к одному"? ("Один ко многим" в данном случае) Size (IDSize,...) Photo (IDPhoto, IDSize_norm, IDSize_small,...) guest_20040621Смысл как раз понятен: конфигурируемая файловая структура В изначальном варианте в поле dir целое число, никаких конфигурируемых файловых систем. Выделять поле с типом "целое" в отдельную таблицу - имхо не очень осмысленно. "Что можно добавить к схеме, чтобы было круто" - вопрос интересный, но напрямую к оптимизации схемы не относящийся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2013, 11:14 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
> В изначальном варианте в поле dir целое число Откуда вдруг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2013, 11:26 |
|
||
|
БД фотогалереи
|
|||
|---|---|---|---|
|
#18+
guest_20040621> В изначальном варианте в поле dir целое число Откуда вдруг? nirana Для работы фотогалереи создала следующие таблицы: fotodivide - id, name ------ таблица разделов subdivide - id, idFD(поле связи с fotodivide), name --------- таблица подразделов foto - id, idSD(поле связи с subdivide), dateUP, description, userId, dir(типа int) , size(varchar), smallsize(varchar) ---- таблица фото users - id и т.д. ------ таблица пользователей tags - id, name ------- таблица тэгов fototag - idfoto, idtag --------- таблица связи тэгов с изображениями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2013, 11:44 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38165688&tid=1541353]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
45ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 369ms |

| 0 / 0 |
