Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Маленький вопрос по поводу скорости
|
|||
|---|---|---|---|
|
#18+
Доброе время суток. Есть база разнообразных объявлений. У всех объевлений всегда есть id, тип, дата создания, текст, телефон и они хранятся в "главной" таблице. Но есть и кучя других параметров характерных для определенного типа объявления. Вот думаю создать дочерние таблицы с дополнительными полями для каждого типа объявлений у которых предок будет "главная" таблица или просто таблицы с дополнительными полями и делать join при выборке. Поскольку база делается для веб, то какой вариант быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 19:39 |
|
||
|
Маленький вопрос по поводу скорости
|
|||
|---|---|---|---|
|
#18+
Saemon ZixelДоброе время суток. Есть база разнообразных объявлений. У всех объевлений всегда есть id, тип, дата создания, текст, телефон и они хранятся в "главной" таблице. Но есть и кучя других параметров характерных для определенного типа объявления. Вот думаю создать дочерние таблицы с дополнительными полями для каждого типа объявлений у которых предок будет "главная" таблица или просто таблицы с дополнительными полями и делать join при выборке. Поскольку база делается для веб, то какой вариант быстрее? Проще всего иметь одну таблицу, которая содержит основные поля (по которым будет поиск, например) и одно поле типа hstore ( contrib/hstore ). Собственно, для таких задач мы и писали этот модуль. И будет тебе счастье. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 23:16 |
|
||
|
Маленький вопрос по поводу скорости
|
|||
|---|---|---|---|
|
#18+
Но у этого подхода есть один момент из-за которого мне пришлось откзаться от наследования и решать всё лапами.... Если вы захотите поставить реляцию от главной таблицы на какой нибудь заказ например (объявление публикуется на основании заказа), то ни чего не выйдет, т.к. само объявление будет в другой таблице (child) и ни чего не получится, констрейн прокричит... Я не понимаю почему создатели записи в подчинённой таблице показывают при выполнении SELECT, а вот при проверке Реляции от парента они считают записей нету... И весь объектный подход насмарку... В общем этот подход пока хорош токо для разбиения головной таблицы на части... Реляцию придётся ставить от кадой child таблицы на заказ... :( Конечно это вопрос к разработчикам....? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2008, 09:15 |
|
||
|
Маленький вопрос по поводу скорости
|
|||
|---|---|---|---|
|
#18+
2SeniorAndre Об этом я не подумал. Реляции естественно будут (это-же РСУБД). 2Oleg Bartunov Почитал про hstore. У предпологаемого хостера стоит PostgreSQL 8.1 и я не знаю есть ли у него hstore, и вообще может ли он его подключить для меня. Также есть вопрос скорости, которая в моем случаи главная. Вобщем я понял что мне как новечку лутче пойти класическим способом, пока-что. Спасибо за дельные ответы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2008, 20:19 |
|
||
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=2004441]: |
0ms |
get settings: |
5ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
38ms |
get topic data: |
7ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 318ms |
| 0 / 0 |
