|
|
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
1. вопрос по больошму количеству полей. если в таблице user нагрузить заранее множество пустых полей, в SQL нет никаких ньюансов связанных с колличеством полей, через что потом запросы будут медленней работать ? 2. в зависимости от того что выберет пользователей, полей может понадобиться больше и разных. Есть много категорий и подкатегорий. Каждая подкатегория должна дать возможность сохранить свои данные. К примеру, пользователь создает обьявление, выбирает категорию, подкатегорию и для идеального поиска нужны конкретные поля. Соображаю использовать только десяток дополнительных полей, которые виртуально потом будут называться по разному. Или еффективность будет от множества подключенных таблиц с совмесным ключем (тоесть скорость не упадет если использовать несколько таблиц связанных по ключу). Или не стоит ? Лучше на одной ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 12:37 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
"Как нихрена не понять и не подать виду." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 12:49 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
уже все порешал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 13:15 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
Андрей159уже все порешал O_o как? :) расскажи, а то я даже не понял что надо... может по ответу хоть понятна задача станет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 13:16 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
В идеале, при проектировании БД лучше сразу определить какие поля будут использоваться. Нарисовать схему, проставить связи. Но если ваше приложение все таки предусматривает не определенное количество полей = атрибутов то тогда два совета: 1. Строить вертикальную структуру таблиц. Т.е ID поля | Значение поля. Но в это подходе есть пару минусов. Во первых необходимо будет выбирать наиболее универсальный тип поля для значения, во вторых необходимо будет выполнять дополнительную сортировку по ключу. Также нужно вести учет идентификаторов полей. 2. Писать динамические SQL запросы. Такой подход позволит избежать головной боле при модификации структуры сущностней относительно приложения в плане целостности данных. Ну и касательно вашего прямого вопроса - на одной не лучше, пустые поля хоть не на что не влияют, но падает ссылочная целостность всей структуры. Вы еще не знаете, что вас ждет дальше. К примеру если вам нужно проверить какой то идентификатор по полю то в двух вариантах вам необходимо выполнить разные движения: 1. Если все в одной таблице - необходимо выбрать запись и проверить значение поля на NULL. 2. Если структура раздельная - само наличие записи говорит о существовании значения. Т.е во втором случае меньше телодвижений. Внешние ключи позволят вам контролировать наполнение и изменение данных. Относительно медленности работы запросов - то здесь есть целая гора разные нюансов которые и влияют на скорости. И исходя из вашего сообщения, сделать какие то выводы - нереально в приницепе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 13:29 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
авторполей может понадобиться больше и разных EAV Модератор: Тема перенесена из форума "PHP, Perl, Python". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 15:04 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
Конечно поделюсь. Я пошел путем запасных полей. Что касается таблицы user - отдельная тема. Будут трудности - буду решать. Делаю объявление. Много категорий, подкатегорий, вложенных подкатегорий до 5 уровня глубины. Но некоторые категорий могут доходить только до второго уровня. Кроме этого, выбранный пунктик может иметь свои поля, или combo (<select>) или list элемент, option, button, check или просто label. Все это нужно будет и отображать как надо и сохранить куда надо и организовать поиск как нужно. Сейчас с ноутбука кину решение. Секундочку... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 23:48 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
На всякий случай сделал 9 таблиц rubr1 ... rubr9. Каждая таблица - свой уровень поля: id NmRubr - название key - связь с id с предыдущей таблицей tp - Тип: id nm 1 категорія 2 підкатегорія (другий рівень) 3 підкатегорія (третій рівень) 4 підкатегорія (четвертий рівень) 5 підкатегорія (п'ятий рівень) 6 підкатегорія (шостий рівень) 7 підкатегорія (сьомий рівень) 8 підкатегорія (восьмий рівень) 9 підкатегорія (дев'ятий рівень) 10 елемент вибору OPTION 11 елемент вибору COMBO 12 елемент вибору LIST 13 елемент списку OPTION 14 елемент списку COMBO 15 елемент списку LIST 16 елемент кнопка 17 елемент TEXT 18 елемент AREATEXT nmpl - имя поля куда сохраняться будет значение которое укажет пользователь lblpl - название метки inxpl - индекс для полей типа <select> -> option valpl - текст по умолчанию tagpl - подсказка Буду решать задачу именно таким способом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 23:57 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
таким образом пользователь должен получить удобный выбор категорий, подкатегорий и заодно ему будет предоставлено сразу пользоваться дополнительными элементами, через которые он или введет текст (параметр) или сделает выбор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 00:02 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
Мой запутанный вопрос вот о чем. Представте. Есть сайт в мешанном стиле "Виндовс" (окна) + немножко из андроид (ярлыки, задачи). Все что делал пользователь, я сохраняю пока что в таблицу user. Например место и размер окна где он оставил в последний раз окно. Завтра он зайдет и должен видеть все так будто ничего не выключал. Все работает, но сайт дорабатывается, количество окон и всяких заморочек будет поеденично увеличиваться и нужно уже с самого начала правильным путем идти. По этому я и спрашиваю о колличестве полей. Например для одного окна я формат сжал в текстовое поле, где свои расшифровки придумал "x=53;y=200;w=617;h=400;s=1;z=1". Что сделать для ярлыков, пока не придумал. Их может быть много. Не хочу чтоб и тормозило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 00:18 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
Андрей159 Например для одного окна я формат сжал в текстовое поленарушение первой нормальной формы. Это не значит что так делать нельзя, это значит что грабли подробно описаны. Андрей159 Что сделать для ярлыков, пока не придумалА если по простому. Завести таблицу Ярлыки, где описать их свойства в том числе принадлежность юзеру. Андрей159 Не хочу чтоб и тормозилоВам надо стремится сделать простую и понятную схему, самым кондовым квадратно-гнездовым способом. Чтобы любой новый человек сразу понял что откуда берется и куда потом деется. И только если линейная схема будет тормозить тогда думать как ее хитровывернуть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 02:02 |
|
||
|
Консультация по количеству полей
|
|||
|---|---|---|---|
|
#18+
авторесли в таблице user нагрузить заранее множество пустых полей, в SQL нет никаких нюансов связанных с количеством полей, через что потом запросы будут медленней работать ? Нет. Но учти, что широкие таблицы как правило говорят о ошибках проектирования БД. Не всё тут однозначно, но очень часто это так. автор2. в зависимости от того что выберет пользователей, полей может понадобиться больше и разных. Есть много категорий и подкатегорий. Каждая подкатегория должна дать возможность сохранить свои данные. К примеру, пользователь создает обьявление, выбирает категорию, подкатегорию и для идеального поиска нужны конкретные поля. Соображаю использовать только десяток дополнительных полей, которые виртуально потом будут называться по разному. Или еффективность будет от множества подключенных таблиц с совмесным ключем (тоесть скорость не упадет если использовать несколько таблиц связанных по ключу). Или не стоит ? Лучше на одной ? Это ниасилил, извини. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 10:17 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38357562&tid=1541149]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
157ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 277ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...