Сколько всего желательно иметь таблиц в базе данных
Есть база данных состоящая из 5 таблиц. В одной храниться порядка 10+ млн записей. Количество записей, кот. нужно еще заполнить, порядка 120-150 млн. Где каждая новая запись записывается на опр. время дольше, чем предыдущая, т.к. идет проверка на дубликаты. И поэтому у меня два пути, оставить как есть и ждать пару недель на сохранения инфы. Или же создать, условно говоря пару тысяч таблиц, для мобильности самой бд, т.к. там используются порядка 2-х тысяч разных типов инфы. И вот для каждого типа инфы, будет использоваться своя таблица. Но не уверен, правильное ли решение. Как поступить? Может есть третье, четвертое и т.д. решение.
Отслеживать
9,103 4 4 золотых знака 20 20 серебряных знаков 28 28 бронзовых знаков
задан 8 июл 2018 в 21:15
277 1 1 золотой знак 3 3 серебряных знака 13 13 бронзовых знаков
что вы подразумеваете под типами инфы. Очевидно, если рецепт кексов вы будете записывать в одну таблицу с характеристиками смартфона, создав для них общий перечень полей. то это не лучшее решение.
8 июл 2018 в 21:39
Информация которая храниться в таблице, это цены на определенные товары, а тип информации, это условно говоря, марка телефона, таких марок около 2-х тысяч
8 июл 2018 в 21:54
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
Если вы можете сразу определить тип инфы с помощью безнес логики то лучше обращаться непосредственно к той таблице у которой этот тип инфы определен. Маленький размер таблицы удобнее использовать. Но если бизнес логика хромает, то время затраченное на поиск нужного типа инфы не окупается по сравнению с индексным поиском этого типа инфы в таблице.
Отслеживать
ответ дан 8 июл 2018 в 21:53
9,103 4 4 золотых знака 20 20 серебряных знаков 28 28 бронзовых знаков
Вся таблица выглядит примерно так (максимально упрощенный вариант), id , type , price , date , где типов порядка 2-х тыс. Поиск же происходит по типу и по времени. А тип записи изначально известен, и я подумал, что если оставить эту структуру дальше такой же, как сейчас, то времени на проверку уходит на порядок больше, чем если создать для каждого типа свою таблицу. Скорость увеличилась более чем в 7 раз. Но вот выглядит это все не эстетично. И думаю, что это не то решение, кот. должно быть.
8 июл 2018 в 22:08
Если вы можете оптимизировать запросы, то это может улучшить время на проверку, но не зная броду не лезь в воду как говорится.
8 июл 2018 в 22:23
Есть база данных состоящая из 5 таблиц. В одной храниться порядка 10+ млн записей. Количество записей, кот. нужно еще заполнить, порядка 120-150 млн. Где каждая новая запись записывается на опр. время дольше, чем предыдущая, т.к. идет проверка на дубликаты.
Если я верно понимаю, то речь идёт о процессе заполнения имеющейся структуры имеющимися данными, и хочется ускорить этот процесс.
В таком случае настоятельно рекомендую выполнить импорт данных во временную структуру без проведения каких-либо проверок (Для MySQL импорт 150кк записей такой простой структуры с применением LOAD DATA INFILE выполняется достаточно быстро), затем выполнить средствами SQL требуемые проверки с удалением дубликатов (и предварительно — необходимые индексирования для быстрого выполнения этих операций), и, наконец, перенос заведомо корректных очищенных данных в боевую таблицу. Для указанных количества и структуры цена вопроса — порядка 3-4 часов.
для каждого типа инфы, будет использоваться своя таблица
А вот тут — полная неясность. Но с учётом того, что
тип информации, это условно говоря, марка телефона, таких марок около 2-х тысяч
скорее всего речь ведётся о простом словаре — тогда вполне достаточно к основной таблице цен иметь ещё одну таблицу с типами телефонов. Но уж никак не две тысячи.
Сколько записей в одной таблице может выдержать myslq?
Полагаю что автору вопроса не стоит задаваться вопросом «Сколько записей в одной таблице может выдержать myslq?», потому что он изначально неверный.
Случай (когда вопрос представляет чисто академический интерес) рассматривать не будем.
Следует задаться другими вопросами:
— мне точно нужен MySQL для решения моей задачи?
— во что я упрусь при большом количестве записей — в ограничение по записи или по чтению?
— при каком объеме памяти в сервере MySQL не сможет эффективно доступаться к данным?
— что такое шардинг, партиционирование и репликация?
— как мне бэкапить базы?
— что будет если моя база упадет?
и т.д. в том же направлении.
Ответ написан более трёх лет назад
Комментировать
Нравится 3 Комментировать
Ответы на вопрос 6
1.844E+19 в таблице типа myisam.
У innodb сложнее найти, но есть ограничение на 64Тб на файл, а значит и на таблицу.
Только эти знания вам никакой практической пользы не принесут.
Ответ написан более трёх лет назад
Комментировать
Нравится 4 Комментировать
Под сотню миллионов держит спокойно, но конечно же таблица жестоко оптимизирована для конкретных достаточно простых запросов. InnoDB.
Переходить на другую СУБД, скорее всего, не стоит. Стоит измерить, насколько плачевная ситуация сейчас и можно ли ее изменить. Проанализируйте, какие запросы идут к таблице, насколько быстро они работают, какие основные операции идут (вставка-чтение), нет ли из-за этого забавных эффектов (например, блокировки на MyISAM и на InnoDB сильно отличаются), все ли индексы стоят, нет ли лишних индексов, нельзя ли их уменьшить и т.д. После этого будете принимать решение. Если сейчас у Вас 1 млн, можно забить тестовую базу на 5 млн и посмотреть, сильно ли изменился расклад.
Общие сведения о таблицах
Таблицы — это неотъемлемая часть любой базы данных, так как именно в них содержатся все сведения и данные. Например, база данных предприятия может содержать таблицу «Контакты», в которой хранятся имена всех поставщиков, их адреса электронной почты и номера телефонов. Так как другие объекты базы данных в значительной степени зависят от таблиц, всегда начинайте разработку базы данных с создания всех таблиц, а уже затем создавайте другие объекты. Прежде чем создавать таблицы в Access, рассмотрите свои требования и определите все таблицы, которые могут потребоваться. Начальные сведения о планировании и разработке баз базы данных см. в статье Основные сведения о создании баз данных.
В этой статье
- Обзор
- Свойства таблиц и полей
- Типы данных
- Отношения между таблицами
- Ключи
- Преимущества использования отношений
Обзор
Обычно реляционная база данных, такая как Access, состоит из нескольких таблиц. В хорошо спроектированной базе данных в каждой таблице хранятся сведения о конкретном объекте, например о сотрудниках или товарах. Таблица состоит из записей (строк) и полей (столбцов). Поля, в свою очередь, содержат различные типы данных: текст, числа, даты и гиперссылки.
- Запись. Содержит конкретные данные, например информацию об определенном работнике или продукте.
- Поле. Содержит данные об одном аспекте элемента таблицы, например имя или адрес электронной почты.
- Значение поля. Каждая запись содержит значение поля, например Contoso, Ltd. или proverka@example.com .
Свойства таблиц и полей
У таблиц и полей также есть свойства, которые позволяют управлять их характеристиками и работой.
1. Свойства таблицы
2. Свойства поля
В базе данных Access свойствами таблицы называются атрибуты, определяющие ее внешний вид и работу. Свойства таблицы задаются на странице свойств таблицы в Конструкторе. Например, вы можете задать для таблицы свойство Режим по умолчанию, чтобы указать, как она должна отображаться по умолчанию.
Свойство поля применяется к определенному полю в таблице и определяет его характеристики или определенный аспект поведения. Некоторые свойства поля можно задать в Режим таблицы. Вы также можете настраивать любые свойства в Конструкторе с помощью области Свойства поля.
Типы данных
У каждого поля есть тип данных. Тип данных поля определяет данные, которые могут в нем храниться (например, большие объемы текста или вложенные файлы).
Тип данных является свойством поля, однако он отличается от других свойств:
- Тип данных поля задается на бланке таблицы, а не в области Свойства поля.
- Тип данных определяет, какие другие свойства есть у этого поля.
- Тип данных необходимо указывать при создании поля. Чтобы создать новое поле в Access, введите данные в новый столбец в режиме таблицы. В таком случае Access автоматически определяет тип данных для поля в зависимости от введенного значения. Если оно не относится к определенному типу, Access выбирает текстовый тип. При необходимости его можно изменить с помощью ленты.
Примеры автоматического определения типа данных
Ниже показано, как выполняется автоматическое определение типа данных в режиме таблицы.
Вводимые данные
Тип данных для поля, назначаемый Access
Вы можете использовать любой допустимый префикс протокола IP. Например, являются допустимыми префиксы http://, https:// и mailto:.
Число, длинное целое
Число, длинное целое
Распознаваемые форматы даты и времени зависят от языкового стандарта.
31 декабря 2016 г.
Распознаваемое обозначение денежной единицы зависит от языкового стандарта.
Отношения между таблицами
Хотя в каждой из таблиц хранятся данные по отдельному объекту, в базе данных Access все они обычно связаны между собой. Ниже приведены примеры таблиц в базе данных.
- Таблица клиентов, содержащая сведения о клиентах компании и их адреса.
- Таблица продаваемых товаров, включающая цены и изображения каждого из них.
- Таблица заказов, служащая для отслеживания заказов клиентов.
Так как данные по разным темам хранятся в отдельных таблицах, их необходимо как-то связать, чтобы можно было легко комбинировать данные из разных таблиц. Для этого используются связи. Связь — это логическое отношение между двумя таблицами, основанное на их общих полях. Дополнительные сведения см. в статье Руководство по связям между таблицами.
Ключи
Поля, формирующие связь между таблицами, называются ключами. Ключ обычно состоит из одного поля, однако может включать и несколько. Есть два вида ключей.
- Первичный ключ. В таблице может быть только один первичный ключ. Он состоит из одного или нескольких полей, однозначно определяющих каждую запись в этой таблице. Часто в качестве первичного ключа используется уникальный идентификатор, порядковый номер или код. Например, в таблице «Клиенты» каждому клиенту может быть назначен уникальный код клиента. Поле кода клиента является первичным ключом этой таблицы. Если первичный ключ состоит из нескольких полей, он обычно включает уже существующие поля, формирующие в сочетании друг с другом уникальные значения. Например, в таблице с данными о людях в качестве первичного ключа можно использовать сочетание фамилии, имени и даты рождения. Дополнительные сведения см. в статье Добавление и изменение первичного ключа таблицы.
- Внешний ключ. В таблице также может быть один или несколько внешних ключей. Внешний ключ содержит значения, соответствующие значениям первичного ключа другой таблицы. Например, в таблице «Заказы» каждый заказ может включать код клиента, соответствующий определенной записи в таблице «Клиенты». Поле «Код клиента» является внешним ключом таблицы «Заказы».
Соответствие значений между полями ключей является основой связи между таблицами. С помощью связи между таблицами можно комбинировать данные из связанных таблиц. Предположим, есть таблицы «Заказчики» и «Заказы». В таблице «Заказчики» каждая запись идентифицируется полем первичного ключа — «Код».
Чтобы связать каждый заказ с клиентом, вы можете добавить в таблицу «Заказы» поле внешнего ключа, соответствующее полю «Код» в таблице «Заказчики», а затем создать связь между этими двумя ключами. При добавлении записи в таблицу «Заказы» можно было бы использовать значение кода клиента из таблицы «Заказчики». При просмотре каких-либо данных о клиенте, сделавшем заказ, связь позволяла бы определить, какие данные из таблицы «Заказчики» соответствуют тем или иным записям в таблице «Заказы».
1. Первичный ключ, который определяется по значку ключа рядом с именем поля.
2. Внешний ключ (определяется по отсутствию значка ключа)
Если ожидается, что для каждого представленного в таблице уникального объекта потребуется несколько значений поля, такое поле добавлять не следует. Обратимся к приведенному выше примеру: если нужно отслеживать размещенные клиентами заказы, не следует добавлять поле в таблицу, поскольку у каждого клиента будет несколько заказов. Вместо этого создается новая таблица для хранения заказов, а затем создаются связи между этими двумя таблицами.
Преимущества использования связей
Раздельное хранение данных в связанных таблицах обеспечивает указанные ниже преимущества.
- Согласованность . Поскольку каждый элемент данных заносится только один раз в одну таблицу, вероятность появления неоднозначных или несогласованных данных снижается. Например, имя клиента будет храниться только в таблице клиентов, а не в нескольких записях в таблице заказов, которые могут стать несогласованными.
- Эффективность . Хранение данных в одном месте позволяет сэкономить место на диске. Кроме того, данные из небольших таблиц извлекаются быстрее, чем из больших. Наконец, если не хранить данные по различным темам в разных таблицах, возникают пустые значения, указывающие на отсутствие данных, или избыточные данные, что может привести к неэффективному использованию места и снижению производительности.
- Простота . Структуру базы данных легче понять, если данные по различным темам находятся в разных таблицах.
Связи между таблицами необходимо иметь в виду еще на этапе планирования таблиц. С помощью мастера подстановок можно создать поле внешнего ключа, если таблица с соответствующим первичным ключом уже существует. Мастер подстановок помогает создать связь. Дополнительные сведения см. в статье Создание и удаление поля подстановки.
Спецификации Access
Эта статья содержит сведения об ограничениях для файлов и объектов баз данных Microsoft Access. В большинстве случаев превышение перечисленных ниже ограничений для базы данных указывает на проблему с ее структурой. Используя информацию, приведенную в этой статье, и тщательно проверив структуру базы данных, вы сможете найти недочеты, которые необходимо устранить для успешного внедрения. Например, импорт данных непосредственно из Microsoft Excel в Access без нормализации может привести к созданию дополнительных полей (столбцов). Если вам нужна информация о проектировании баз данных или нормализации, воспользуйтесь ссылками в разделе Дополнительные сведения.
В этой статье
- Спецификации базы данных
- Спецификации проекта
- Дополнительные сведения
Спецификации базы данных
Сведения в приведенных ниже таблицах относятся к базам данных Access. Различия конкретных версий (если они есть) упоминаются отдельно
Общие спецификации
Максимальное значение
Общий размер базы данных Access (ACCDB- или MDB-файла), включая все объекты и данные
2 ГБ за вычетом места, необходимого для системных объектов.
Примечание: Это ограничение можно обойти, создав связи с таблицами из других баз данных Access. Вы можете создать связи с таблицами из нескольких файлов баз данных, максимальный размер каждого из которых составляет 2 ГБ.
Общее количество объектов в базе данных
Количество модулей (включая формы и отчеты, у которых свойство HasModule имеет значение Истина)
Количество символов в имени объекта
Количество символов в пароле
Примечание: В Access 2007 пароль может содержать 20 символов.
Количество символов в имени пользователя или группы
Количество одновременно работающих пользователей
Таблица
Максимальное значение
Количество символов в имени таблицы
Количество символов в имени поля
Количество полей в таблице
Количество открытых таблиц
Для Microsoft 365 версий Access, 4096, включая связанные таблицы и таблицы, открытые внутри Access.
Для версий Access, отличных отMicrosoft 365, 2048, включая связанные таблицы и таблицы, открытые внутри Access.
Количество доступных подключений
512 для Microsoft 365 версий Access.
256 для версий Access, отличных отMicrosoft 365.
2 ГБ за вычетом места, необходимого для системных объектов
Количество символов в поле «Короткий текст»
Примечание: В Access 2013 и более поздних версий поля «Текст» заменены полями «Короткий текст».
Количество символов в поле «Длинный текст»
Примечание: В Access 2013 и боле поздних версий поля Memo заменены полями «Длинный текст».
65 535 при вводе данных через пользовательский интерфейс;
1 гигабайт хранения символов при вводе данных программным способом
Размер поля «Объект OLE»
Количество индексов в таблице
32, включая индексы для внутренних целей (созданные для поддержки связей между таблицами), индексы по одному полю и составные индексы
Количество полей в индексе или первичном ключе
Количество символов в сообщении о проверке
Количество символов в правиле проверки, включая знаки пунктуации и операторы
Количество символов в описании поля или таблицы
Количество символов в записи (кроме полей «Длинный текст» и «Объект OLE»), когда для свойства полей UnicodeCompression задано значение Да
Количество символов в значении свойства поля
Запрос
Максимальное значение
Количество установленных связей
32 на одну таблицу за вычетом количества индексов этой таблицы, созданных для полей или сочетаний полей, которые не участвуют в связях *
Количество таблиц в запросе
Количество соединений в запросе
Количество полей в наборе записей
Размер набора записей
255 символов в одном или нескольких полях
Количество уровней вложенности запросов
Количество символов в ячейке в бланке запроса
Количество символов для параметра в запросе с параметрами
Количество операторов AND в предложении WHERE или HAVING
Количество символов в инструкции SQL
Приблизительно 64 000 *
* Максимальные значения могут быть меньше, если запрос содержит многозначные поля подстановки (только для ACCDB-файлов).
Форма и отчет
Максимальное значение
Количество символов в метке
Количество символов в текстовом поле
Ширина формы или отчета
22,75 in. (57,79 см)
22.75 in. (57,79 см)
Высота всех разделов вместе с заголовками (в Конструкторе)
Количество уровней вложенности форм или отчетов
Количество полей или выражений, которые можно сортировать или группировать в отчете
Количество заголовков и примечаний в отчете
1 верхний и нижний колонтитул отчета;
1 колонтитул страницы;
10 колонтитулов группы
Количество печатных страниц в отчете
Количество элементов управления и разделов, которые можно добавить в течение жизненного цикла формы или отчета
Количество символов в инструкции SQL, которая служит свойством Recordsource или Rowsource для формы, отчета или элемента управления.
Макрос
Максимальное значение
Количество макрокоманд в макросе
Количество символов в условии
Количество символов в комментарии
Количество символов в аргументе макрокоманды
Спецификации проекта
Следующий список таблиц относится к проектам Access ADP:
Общие спецификации
Максимальное значение
Количество объектов в проекте Access (ADP-файле)
Количество модулей (включая формы и отчеты, у которых свойство HasModule имеет значение Истина)
Количество символов в имени объекта
Количество столбцов в таблице
250 (Microsoft SQL Server 6.5)
1024 (Microsoft SQL Server 7.0, 2000 и 2005)
Форма и отчет
Максимальное значение
Количество символов в метке
Количество символов в текстовом поле
Ширина формы или отчета
Высота всех разделов вместе с заголовками (в Конструкторе)
Количество уровней вложенности форм или отчетов
Количество полей или выражений, которые можно сортировать или группировать в отчете
Количество заголовков и примечаний в отчете
1 верхний и нижний колонтитул отчета;
1 колонтитул страницы;
10 колонтитулов группы
Количество печатных страниц в отчете
Количество элементов управления и разделов, которые можно добавить в течение жизненного цикла формы или отчета
Количество символов в инструкции SQL, служащей значением свойства Recordsource или Rowsource формы, отчета или элемента управления (для ACCDB- и ADP-файлов)
Макрос
Максимальное значение
Количество макрокоманд в макросе
Количество символов в условии
Количество символов в комментарии
Количество символов в аргументе макрокоманды
Дополнительные сведения
- Основные сведения о создании баз данных
- Структура базы данных Access
- Защита данных с помощью резервного копирования и восстановления
Нужна дополнительная помощь?
Нужны дополнительные параметры?
Изучите преимущества подписки, просмотрите учебные курсы, узнайте, как защитить свое устройство и т. д.
В сообществах можно задавать вопросы и отвечать на них, отправлять отзывы и консультироваться с экспертами разных профилей.