1 большая таблица против 10 поменьше

@kkeiv · Регистрация: 27.01.2016

Студворк — интернет-сервис помощи студентам

Кто может подсказать на базе своего опыта?
Есть объект с 10000 параметров (в основном описывается int или double).
В принципе сгруппировать эти параметры по группам возможно, и сделать в виде связи 1к1 в отдельных таблицах.
Объектов порядка 5000 (теоретически в далекой перспективе возможно расширение до 10000)
Основные запросы update (1 или 2 параметра достаточно активно) и select 2 параметров

Вопрос:
Есть 3 варианта реализации:
- 1 большая таблица
- несколько таблиц поменьше с разбиением по функционалу
- несколько таблиц поменьше с разбиением по частоте апдейтов

Есть ли смысл разбивать по таблицам?
Не будет ли тормозов при использовании 1 таблицей?
Либо разбить на таблицы по активности апдейта (есть понимание какие параметры будут апдейтиться чаще остальных) - тут возникает вопрос с трудностью дальнейшего обслуживания, т.к. будет все запутано.

quwy · 27.01.2016, 16:34

InnoDB позволяет создавать не более 1000 полей на таблицу (а 4096 -- жесткий лимит ядра MySQL для всех движков) и не более 65535 байт общего размера записи. Так что разбивайте, так и жить потом легче будет.

@kkeiv · 28.01.2016, 09:59 **[ТС]**

Используем InnoDB. С 1000 - ок. Спасибо.
А бить лучше по 1000 или по 250 к примеру.
С учетом что много апдейтов только части (1, 2 столбца).
Выборка для чтения производится по 1 индексированному столбцу (ID объекта). Поиск объектов по статусу определенных параметров производится редко.

Оптимизацией на мой взгяд в таком случае может быть:
- вынести все параметры, описываемые строками переменной длинны в связанную таблицу
- вынести все параметры с большим кол-вом обновлений в связанные таблицы

Есть еще идеи по опыту, чтобы предусмотреть в моем случае?

quwy · 28.01.2016, 12:39

Разбивайте так, чтобы было удобнее работать, количество полей не принципиально.

Сообщение от kkeiv

Оптимизацией на мой взгяд в таком случае может быть:
- вынести все параметры, описываемые строками переменной длинны в связанную таблицу
- вынести все параметры с большим кол-вом обновлений в связанные таблицы

Ни то ни другое не принципиально. Разве что лимит 64 килобайта на запись может заставить. А так движку не принципиально, это все-таки не DBF-файл.

@ApXyC · 28.01.2016, 17:15

kkeiv, почему Вы хотите хранить 1000 свойств объекта в колонках? Я бы создал таблицу свойств, где и хранил бы 1000 записей на объект, а значения свойств в соответствующих колонках Value_int, Value_double и т.д.
Ни разу на практике не встречал таблицу больше чем на 200 полей.

Добавлено через 1 минуту
как поддерживать-то такую таблицу - свихнешься )

Новые блоги и статьи Все статьи Все блоги /
Functional First Web Framework Suave DevAlt 30.03.2026 Sauve. IO Апнулись до NET10. Из зависимостей один пакет, работает одинаково хорошо как в режиме проекта так и в интерактивном режиме. из сложностей - чисто функциональный подход. Решил. . .	Автоматическое создание документа при проведении другого документа Maks 29.03.2026 Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2. Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники". В. . .	Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .	Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .
Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .	Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .

@kkeiv 0 / 0 / 0 Регистрация: 27.01.2016 Сообщений: 2

	1 большая таблица против 10 поменьше 27.01.2016, 16:20. Показов 1612. Ответов 4 Метки нет (Все метки) Кто может подсказать на базе своего опыта? Есть объект с 10000 параметров (в основном описывается int или double). В принципе сгруппировать эти параметры по группам возможно, и сделать в виде связи 1к1 в отдельных таблицах. Объектов порядка 5000 (теоретически в далекой перспективе возможно расширение до 10000) Основные запросы update (1 или 2 параметра достаточно активно) и select 2 параметров Вопрос: Есть 3 варианта реализации: - 1 большая таблица - несколько таблиц поменьше с разбиением по функционалу - несколько таблиц поменьше с разбиением по частоте апдейтов Есть ли смысл разбивать по таблицам? Не будет ли тормозов при использовании 1 таблицей? Либо разбить на таблицы по активности апдейта (есть понимание какие параметры будут апдейтиться чаще остальных) - тут возникает вопрос с трудностью дальнейшего обслуживания, т.к. будет все запутано. 0

quwy Native x86 6859 / 3791 / 1026 Регистрация: 13.02.2013 Сообщений: 11,861
	27.01.2016, 16:34
	InnoDB позволяет создавать не более 1000 полей на таблицу (а 4096 -- жесткий лимит ядра MySQL для всех движков) и не более 65535 байт общего размера записи. Так что разбивайте, так и жить потом легче будет. 1

@kkeiv 0 / 0 / 0 Регистрация: 27.01.2016 Сообщений: 2
	28.01.2016, 09:59 [ТС]
	Используем InnoDB. С 1000 - ок. Спасибо. А бить лучше по 1000 или по 250 к примеру. С учетом что много апдейтов только части (1, 2 столбца). Выборка для чтения производится по 1 индексированному столбцу (ID объекта). Поиск объектов по статусу определенных параметров производится редко. Оптимизацией на мой взгяд в таком случае может быть: - вынести все параметры, описываемые строками переменной длинны в связанную таблицу - вынести все параметры с большим кол-вом обновлений в связанные таблицы Есть еще идеи по опыту, чтобы предусмотреть в моем случае? 0

@ApXyC 66 / 64 / 24 Регистрация: 14.10.2014 Сообщений: 339
	28.01.2016, 17:15
	kkeiv, почему Вы хотите хранить 1000 свойств объекта в колонках? Я бы создал таблицу свойств, где и хранил бы 1000 записей на объект, а значения свойств в соответствующих колонках Value_int, Value_double и т.д. Ни разу на практике не встречал таблицу больше чем на 200 полей. Добавлено через 1 минуту как поддерживать-то такую таблицу - свихнешься ) 0