Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
маленький вопрос по проектированию БД (decompose or not?)
|
|||
|---|---|---|---|
|
#18+
Планируется база данных доски объявлений. Видов объявлений много, они разнородные и с разными свойствами, поэтому сделать одну таблицу для всех объявлений не получится. Но у многих видов объявлений есть одинаковые наборы свойств (например, контактная информация или характеристики объекта недвижимости). Есть мысль сделать декомпозицию, - выделить одинаковые наборы свойств в отдельные сущности. Но есть сомнение. Ведь это приведёт к тому, что в таких "выделенных" таблицах будут очень большие объёмы данных. Не замедлит ли это выборку информации? Ведь большая (или бОльшая) часть SELECT'ов будет join'ами из тяжёлой таблицы и другой таблицы? С учётом этого, как лучше поступить - вынести контактную информацию из объявлений в отдельную таблицу или делать десяток таблиц, у каждой из которых будет по нескольку одинаковых полей? P.S.: База - MySQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 16:00 |
|
||
|
маленький вопрос по проектированию БД (decompose or not?)
|
|||
|---|---|---|---|
|
#18+
D.O. Но есть сомнение. Ведь это приведёт к тому, что в таких "выделенных" таблицах будут очень большие объёмы данных. Не замедлит ли это выборку информации? Ведь большая (или бОльшая) часть SELECT'ов будет join'ами из тяжёлой таблицы и другой таблицы? С учётом этого, как лучше поступить - вынести контактную информацию из объявлений в отдельную таблицу или делать десяток таблиц, у каждой из которых будет по нескольку одинаковых полей? P.S.: База - MySQL. Зависит от того, какие отчёты вам будут нужны, и сколько эта доска объявлений будет жить. Конечно, выбрать контактную информацию из сосених полей для заданого сообщения будет быстрее, однако без знания того как Вы видите эту систему, ответить однозначно довольно тяжело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 16:43 |
|
||
|
маленький вопрос по проектированию БД (decompose or not?)
|
|||
|---|---|---|---|
|
#18+
авторЗависит от того, какие отчёты вам будут нужны Будет производиться выборка всех объявлений, не более старых, чем выбранный промежуток времени назад. Выводиться будут заголовки объявлений на одной странице, на другой - не только заголовок и текст объявления, но и контактная информация. По некоторым видам объявлений будет доступен поиск. Объявлений предполагается много, тысячи точно. Количество видов объявлений - около десятка. Количество объявлений для разных видов объявлений будет сильно отличаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 17:45 |
|
||
|
маленький вопрос по проектированию БД (decompose or not?)
|
|||
|---|---|---|---|
|
#18+
Тогда есть предложение вынести контактную информацию в отдельную таблицу. Все объявления хранить в одной таблице, но сделать справочник к какому типу относится объявление (недвижимость, движимость :-) итд ). В таблице "объявление" должен быть ключ контакта и ключ типа объявления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2004, 18:32 |
|
||
|
маленький вопрос по проектированию БД (decompose or not?)
|
|||
|---|---|---|---|
|
#18+
mysql дурной сервак он блокирует записи при чтении (т.е. пока делаем инсерт не можем читать, пока читаем не может инсертить) по сему все транзакции и все операторы должны быть очень быстрыми теперь по существу: делай три таблицы 1. объявления (тут все общие поля для всех типов объявлений) 2. дополнительные аттрибуты объявления (тут будут все специфические поля) 3. справочник дополнительных аттрибутов объявлений и их видов и все ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2004, 15:28 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32790034&tid=1546164]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
40ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 312ms |

| 0 / 0 |
