ReSQL.ru
     
powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура данных
25 сообщений из 29, страница 1 из 2
  1  все
Структура данных
    #39788757
vladka63
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vladka63
Участник
Добрый день!

Уважаемые практики, дайте пожалуйста совет.

Предположим есть много пользователей (пусть 500 тысяч или 1 млн).
Данные пользователей (пусть 80 колонок с данными) могут храниться:
1. все в одной таблице, т.е 500 - 1 млн записей в таблице по 80 колонок;
2. по заполнению для каждого пользователя динамически (программно) создается своя, отдельная таблица, т.е 1 млн. отдельных, для каждого пользователя, с одинаковой структурой, таблиц.


Какой вариант предпочтительней с точки зрения производительности и скорости обработки данных?

Спасибо :-)
...
Рейтинг: 0 / 0
20.03.2019, 08:01
| Ответить | Цитировать | Написать  
Структура данных
    #39788777
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Озверин
Участник
vladka63, таки надо понять, производительность чего вы измеряете? (вставка, чтение, обновление, удаление). Видимо с этим же показателем и связано наиболее частые операции.
Насчет второго варианта мне он кажется подозрительным....
Например, обновление свойств у нескольких пользователей как будет выглядеть?
А выборка свойств для нескольких пользователей?

Это вопросы к "производительности" - часть операций на плоской многоколоночной таблице будут быстрее(чтение, например).
Часть операций могут быть медленее из-за блокировок, к примеру. Но если выбор из этих двух вариантов - я бы предпочел многоколоночное решение.

Чтобы местная публика продолжила дискуссию, думается, надо накидать операции, производительность которых вы желаете "измерять".

p.s. При таком небольшом кол-ве данных их всегда можно сгененрировать и измерить прямо не отходя от кассы.
...
Рейтинг: 0 / 0
20.03.2019, 08:43
| Ответить | Цитировать | Написать  
Структура данных
    #39788815
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
п. 2 какой-то бред, ИМХО.

Если из 80 колонок в большинстве случаев заполнены всего 5-6 параметров, то можно рассмотреть EAV. Это еще пара таблиц(справочник и данные), где каждый параметр пользователя хранится в отдельной записи. Также можно хранить исторические данные, т.е. зависящие от времени.
...
Рейтинг: 0 / 0
20.03.2019, 09:49
| Ответить | Цитировать | Написать  
Структура данных
    #39788816
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
982183
Участник
А какая СУБД потянет такое количество таблиц в одной базе?
...
Рейтинг: 0 / 0
20.03.2019, 09:51
| Ответить | Цитировать | Написать  
Структура данных
    #39788817
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
982183А какая СУБД потянет такое количество таблиц в одной базе?Никакая. Это бред ТСа :)
...
Рейтинг: 0 / 0
20.03.2019, 09:53
| Ответить | Цитировать | Написать  
Структура данных
    #39788821
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
s_ustinov
Участник
vladka63Добрый день!

Уважаемые практики, дайте пожалуйста совет.

Предположим есть много пользователей (пусть 500 тысяч или 1 млн).
Данные пользователей (пусть 80 колонок с данными) могут храниться:
1. все в одной таблице, т.е 500 - 1 млн записей в таблице по 80 колонок;
2. по заполнению для каждого пользователя динамически (программно) создается своя, отдельная таблица, т.е 1 млн. отдельных, для каждого пользователя, с одинаковой структурой, таблиц.


Какой вариант предпочтительней с точки зрения производительности и скорости обработки данных?

Спасибо :-)
А вот, например, задача - отобрать всех пользователей, которые родились раньше 1990 года. Как вы будете решать эту задачу во втором случае и какая будет производительность?
...
Рейтинг: 0 / 0
20.03.2019, 09:58
| Ответить | Цитировать | Написать  
Структура данных
    #39788840
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
vladka63Какой вариант предпочтительней
Нанять специалиста.
...
Рейтинг: 0 / 0
20.03.2019, 10:18
| Ответить | Цитировать | Написать  
Структура данных
    #39788843
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
vladka63,

Ни первый, ни второй вариант. Нужно рассмотреть существование нескольких таблиц - справочники, однотипные данные. Наверняка можно всё выложить в 80 полей, а-ля Эксель. И это будет редкозаполненная матрица. Это нехорошо. Вернее даже не так. Для чего эта таблица? Нужно будет потом делать анализ, выборки из этой матрицы. И скорее всего, выборки будут по столбцам. Как вариант - база с "колоночным" хранением (или как там по-научному называется).
...
Рейтинг: 0 / 0
20.03.2019, 10:21
| Ответить | Цитировать | Написать  
Структура данных
    #39789174
МодальноеОкно
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МодальноеОкно
Участник
vladka63Какой вариант предпочтительней с точки зрения производительности и скорости обработки данных?

покурить про нормализацию данных. выделить отдельные сущности
...
Рейтинг: 0 / 0
20.03.2019, 17:34
| Ответить | Цитировать | Написать  
Структура данных
    #39789175
МодальноеОкно
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МодальноеОкно
Участник
vladka63Какой вариант предпочтительней

пойти в кондукторы
...
Рейтинг: 0 / 0
20.03.2019, 17:35
| Ответить | Цитировать | Написать  
Структура данных
    #39789281
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
982183А какая СУБД потянет такое количество таблиц в одной базе?
...
Рейтинг: 0 / 0
20.03.2019, 22:34
| Ответить | Цитировать | Написать  
Структура данных
    #39789282
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
982183А какая СУБД потянет такое количество таблиц в одной базе?
Oracle
...
Рейтинг: 0 / 0
20.03.2019, 22:34
| Ответить | Цитировать | Написать  
Структура данных
    #39789305
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
982183
Участник
Чисто теоретически:
И как вы оцениваете затраты СУБД на обработку такого количества таблиц?
...
Рейтинг: 0 / 0
21.03.2019, 03:34
| Ответить | Цитировать | Написать  
Структура данных
    #39789442
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
982183,

Мы ж не знаем целевой функции, может задача освоить бюджет
...
Рейтинг: 0 / 0
21.03.2019, 11:04
| Ответить | Цитировать | Написать  
Структура данных
    #39789506
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
982183
Участник
Выбить финансирование на новый сервер....
...
Рейтинг: 0 / 0
21.03.2019, 12:24
| Ответить | Цитировать | Написать  
Структура данных
    #39789539
МодальноеОкно
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МодальноеОкно
Участник
982183Выбить финансирование на новый сервер....

+ лучше с запасом - квантовый
...
Рейтинг: 0 / 0
21.03.2019, 13:18
| Ответить | Цитировать | Написать  
Структура данных
    #39790347
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Только этот вариант!
авторДанные пользователей (пусть 80 колонок с данными) могут храниться:
1. все в одной таблице, т.е 500 - 1 млн записей в таблице по 80 колонок;

В БД во время штатной работы системы (программы) не должны создаваться новые таблицы,
иначе это ошибка проектирования БД.


авторКакой вариант предпочтительней с точки зрения производительности и скорости обработки данных?


На самом деле всё равно с этой точки зрения.

А вот попросят тебя посчитать какую-то статистику ПО ВСЕМ ПОЛЬЗОВАТЕЛЯМ -- что ты скажешь начальству
своему? Что плохо учился в школе и не умеешь БД проектировать?
Или будешь динамический запрос на 500тысяч таблиц собирать?
Ну так тебя тут же и уволят...
...
Рейтинг: 0 / 0
23.03.2019, 01:16
| Ответить | Цитировать | Написать  
Структура данных
    #39790778
Mr.Fontaine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr.Fontaine
Участник
vladka63, из этих двух однозначно первый.
да и при хорошей индексации таблицы, он предпочтительней того же EAV.
Делай одну таблицу, навешивай нужные индексы. Всё будет работать без видимых глазу задержек.
У самого есть таблица 73 миллиона записей (правда полей только 61)
Как-то даже и не замечает никто что там размер таблицы 24 гигабайта.
...
Рейтинг: 0 / 0
25.03.2019, 09:50
| Ответить | Цитировать | Написать  
Структура данных
    #39791033
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
vladka632. по заполнению для каждого пользователя динамически (программно) создается своя, отдельная таблица, т.е 1 млн. отдельных, для каждого пользователя, с одинаковой структурой, таблиц.
Ерунда какая-то. Так не проектируют БД.
...
Рейтинг: 0 / 0
25.03.2019, 16:11
| Ответить | Цитировать | Написать  
Структура данных
    #39791304
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Mr.Fontainevladka63, из этих двух однозначно первый.
да и при хорошей индексации таблицы, он предпочтительней того же EAV.
Делай одну таблицу, навешивай нужные индексы. Всё будет работать без видимых глазу задержек.
У самого есть таблица 73 миллиона записей (правда полей только 61)
Как-то даже и не замечает никто что там размер таблицы 24 гигабайта.Этот подход не годится. Очень часто придется добавлять новые параметры. А это новые поля. Добавить на лету новое поле в таблицу с 100млн. записей - стрёмное занятие. Иногда еще придется и удалять/переопределять.
Правильное решение - новый параметр это просто новая запись(и) в табличке(ах). Его легко добавить/удалить/изменить
...
Рейтинг: 0 / 0
26.03.2019, 09:56
| Ответить | Цитировать | Написать  
Структура данных
    #39791328
Mr.Fontaine
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr.Fontaine
Участник
L_argo, в каких-то случаях, да. Правильное решение - EAV. В каких-то нет. Нет единого правильного решения.

P.S. Тем более в исходных данных варианта "новый параметр это просто новая запись(и) в табличке(ах)." вообще нет.
Там всего из двух пунктов выбор.
...
Рейтинг: 0 / 0
26.03.2019, 10:23
| Ответить | Цитировать | Написать  
Структура данных
    #39791339
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ПЕНСИОНЕРКА
Участник
vladka63Предположим есть много пользователей (пусть 500 тысяч или 1 млн).
Данные пользователей (пусть 80 колонок с данными) могут храниться:
1. все в одной таблице, т.е 500 - 1 млн записей в таблице по 80 колонок;
2. по заполнению для каждого пользователя динамически (программно) создается своя, отдельная таблица,
я бы предложила 3-й вариант(и несколько раз я его применяла)
-- основная таблица (до 10 полей, например kod1,фио,дата рождения,пол,,,)
--и десяток подчиненных(у меня было до 26), в каждой по 5-10 связанных логически полей
2.родственники(код2,код1,степень родства......)
3.адреса(код3,код1,тип адреса ,код региона, код города,.........)
4.образование(код4,код1,.......)
5.место работы......
6.награды....
7.наказания......
.....
...
Рейтинг: 0 / 0
26.03.2019, 10:42
| Ответить | Цитировать | Написать  
Структура данных
    #39791345
982183
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
982183
Участник
Вполне стандартный подход.
Обязательные поля в основной таблице.
Необязательные или многозначные в EAV.

Видел извращения в виде отдельной EAV таблицы для данных определенного типа.
...
Рейтинг: 0 / 0
26.03.2019, 10:48
| Ответить | Цитировать | Написать  
Структура данных
    #39791356
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ПЕНСИОНЕРКА
Участник
vladka63Какой вариант предпочтительней с точки зрения производительности и скорости обработки данных?
вариантов обработки -3
1-с головы, с основной таблички,
--выбираем по фио,дата рождения,пол,
--на выбранную запись навешиваем выбранные из подчиненных(по потребности) по код1
2- с подчиненных
--ищем жителей ТУЛА и получаем таблицу раб11 с код1
--ищем образование ВЫСШЕЕ ЭКОНОМИЧЕСКОЕ по образованию+раб11 , получаем раб12
3- динамическое формирование запроса(выбираются поля и формируется строка запроса
--нет смысла прицеплять подчиненные, если от них не нужна информация)
-- select....from основная inner join t_adres ..... inner join t_obrasovanie.....
...
Рейтинг: 0 / 0
26.03.2019, 11:00
| Ответить | Цитировать | Написать  
Структура данных
    #39791360
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ПЕНСИОНЕРКА
Участник
982183Видел извращения в виде отдельной EAV таблицы для данных определенного типа.
вполне разумно для
--мемо(встречала до 50кб, предпочитаю до 1кб, а то и по-параграфно)
--оле + некий текст или место первоисточника
--вложения(строго 1 вложение в записи + некий текст или место первоисточника)
...
Рейтинг: 0 / 0
26.03.2019, 11:06
| Ответить | Цитировать | Написать  
25 сообщений из 29, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура данных
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=39791356&tid=1539947]:
 0ms
get settings:
 12ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 48ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 74ms
get tp. blocked users:
 2ms
others: 245ms
total:  419ms
созд. / загр.: 419ms
x
x
Закрыть


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