powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Консультация по количеству полей
13 сообщений из 13, страница 1 из 1
Консультация по количеству полей
    #38356414
Фотография Андрей159
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. вопрос по больошму количеству полей. если в таблице user нагрузить заранее множество пустых полей, в SQL нет никаких ньюансов связанных с колличеством полей, через что потом запросы будут медленней работать ?

2. в зависимости от того что выберет пользователей, полей может понадобиться больше и разных. Есть много категорий и подкатегорий. Каждая подкатегория должна дать возможность сохранить свои данные. К примеру, пользователь создает обьявление, выбирает категорию, подкатегорию и для идеального поиска нужны конкретные поля. Соображаю использовать только десяток дополнительных полей, которые виртуально потом будут называться по разному. Или еффективность будет от множества подключенных таблиц с совмесным ключем (тоесть скорость не упадет если использовать несколько таблиц связанных по ключу). Или не стоит ? Лучше на одной ?
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38356445
apajan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
"Как нихрена не понять и не подать виду."
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38356485
Фотография Андрей159
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
уже все порешал
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38356488
Програмёр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей159уже все порешал

O_o как? :) расскажи, а то я даже не понял что надо... может по ответу хоть понятна задача станет.
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38356511
Electric200
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В идеале, при проектировании БД лучше сразу определить какие поля будут использоваться. Нарисовать схему, проставить связи.
Но если ваше приложение все таки предусматривает не определенное количество полей = атрибутов то тогда два совета:

1. Строить вертикальную структуру таблиц. Т.е ID поля | Значение поля. Но в это подходе есть пару минусов. Во первых необходимо будет выбирать наиболее универсальный тип поля для значения, во вторых необходимо будет выполнять дополнительную сортировку по ключу. Также нужно вести учет идентификаторов полей.
2. Писать динамические SQL запросы.

Такой подход позволит избежать головной боле при модификации структуры сущностней относительно приложения в плане целостности данных.

Ну и касательно вашего прямого вопроса - на одной не лучше, пустые поля хоть не на что не влияют, но падает ссылочная целостность всей структуры. Вы еще не знаете, что вас ждет дальше. К примеру если вам нужно проверить какой то идентификатор по полю то в двух вариантах вам необходимо выполнить разные движения:
1. Если все в одной таблице - необходимо выбрать запись и проверить значение поля на NULL.
2. Если структура раздельная - само наличие записи говорит о существовании значения.

Т.е во втором случае меньше телодвижений. Внешние ключи позволят вам контролировать наполнение и изменение данных.

Относительно медленности работы запросов - то здесь есть целая гора разные нюансов которые и влияют на скорости. И исходя из вашего сообщения, сделать какие то выводы - нереально в приницепе.
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38356742
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторполей может понадобиться больше и разных
EAV

Модератор: Тема перенесена из форума "PHP, Perl, Python".
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38357562
Фотография Андрей159
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Конечно поделюсь.
Я пошел путем запасных полей.
Что касается таблицы user - отдельная тема. Будут трудности - буду решать.

Делаю объявление. Много категорий, подкатегорий, вложенных подкатегорий до 5 уровня глубины. Но некоторые категорий могут доходить только до второго уровня. Кроме этого, выбранный пунктик может иметь свои поля, или combo (<select>) или list элемент, option, button, check или просто label. Все это нужно будет и отображать как надо и сохранить куда надо и организовать поиск как нужно.
Сейчас с ноутбука кину решение. Секундочку...
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38357575
Фотография Андрей159
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На всякий случай сделал 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 - подсказка

Буду решать задачу именно таким способом
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38357579
Фотография Андрей159
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
таким образом пользователь должен получить удобный выбор категорий, подкатегорий и заодно ему будет предоставлено сразу пользоваться дополнительными элементами, через которые он или введет текст (параметр) или сделает выбор.
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38357588
Фотография Андрей159
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мой запутанный вопрос вот о чем. Представте. Есть сайт в мешанном стиле "Виндовс" (окна) + немножко из андроид (ярлыки, задачи). Все что делал пользователь, я сохраняю пока что в таблицу user. Например место и размер окна где он оставил в последний раз окно. Завтра он зайдет и должен видеть все так будто ничего не выключал. Все работает, но сайт дорабатывается, количество окон и всяких заморочек будет поеденично увеличиваться и нужно уже с самого начала правильным путем идти. По этому я и спрашиваю о колличестве полей. Например для одного окна я формат сжал в текстовое поле, где свои расшифровки придумал "x=53;y=200;w=617;h=400;s=1;z=1". Что сделать для ярлыков, пока не придумал. Их может быть много. Не хочу чтоб и тормозило.
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38357640
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей159 Например для одного окна я формат сжал в текстовое поленарушение первой нормальной формы. Это не значит что так делать нельзя, это значит что грабли подробно описаны.
Андрей159 Что сделать для ярлыков, пока не придумалА если по простому. Завести таблицу Ярлыки, где описать их свойства в том числе принадлежность юзеру.
Андрей159 Не хочу чтоб и тормозилоВам надо стремится сделать простую и понятную схему, самым кондовым квадратно-гнездовым способом. Чтобы любой новый человек сразу понял что откуда берется и куда потом деется. И только если линейная схема будет тормозить тогда думать как ее хитровывернуть.
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38357830
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторесли в таблице user нагрузить заранее множество пустых полей, в SQL нет никаких нюансов связанных с количеством полей, через что потом запросы будут медленней работать ?


Нет. Но учти, что широкие таблицы как правило говорят о ошибках проектирования БД. Не всё тут однозначно, но очень часто это так.

автор2. в зависимости от того что выберет пользователей, полей может понадобиться больше и разных. Есть много категорий и подкатегорий. Каждая подкатегория должна дать возможность сохранить свои данные. К примеру, пользователь создает обьявление, выбирает категорию, подкатегорию и для идеального поиска нужны конкретные поля. Соображаю использовать только десяток дополнительных полей, которые виртуально потом будут называться по разному. Или еффективность будет от множества подключенных таблиц с совмесным ключем (тоесть скорость не упадет если использовать несколько таблиц связанных по ключу). Или не стоит ? Лучше на одной ?

Это ниасилил, извини.
...
Рейтинг: 0 / 0
Консультация по количеству полей
    #38358128
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей159 Что сделать для ярлыков, пока не придумал. Их может быть много. Не хочу чтоб и тормозило.

Делать отдельную таблицу, 1:N с данной.
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Консультация по количеству полей
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]