powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хранение auto_increment поля в отдельной таблице
15 сообщений из 15, страница 1 из 1
Хранение auto_increment поля в отдельной таблице
    #37071738
Рубик6
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть система состоящая из множества таблиц (CMS). Каждый плагин, подключаемый к CMS, может создавать свои таблицы. В таблицах хранятся поля каких-то объектов. В привычном варианте в каждую таблицу добавляется ID -- primary_key и auto_increment поле, по которому и происходит выборка конкретных объектов -- наверное, это знакомо каждому.

Но, в целях унификации, появилась идея вынести все ID всех объектов в отдельную таблицу -- т.е. создать таблицу objects, в которой и сделать единственное auto_increment поле, а во всех остальных -- FK object_id, ссылающийся на соответствующую запись в objects. Все выборки в этом случае прийдется делать из двух таблиц, а вставки -- сразу в две транзакцией.

Все выглядит неплохо, однако смущает, что таблица objects может непомерно разрастись, а все равно практически все запросы, как выборки, так и вставки, нужно делать через нее. Я раньше не сталкивался с подобной архитектурой, поэтому интересует, приемлемо такое решение или лучше от него отказаться? Если ли у вас опыт подобной унификации?

База MySQL InnoDB.
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37071789
tru55
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Удвоение операций SELECT и DML для КАЖДОЙ строки - весьма сомнительно, с точки зрения производительности
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072091
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рубик6,

Не понятно: как у вас сейчас ID объектов генерятся и, как будут генериться.

Зачем в каждой таблице auto_increment поле?
Одна таблица == один класс объектов? И вы хотите создать справочник классов?
Или я все не так понял...
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072117
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот чисто любопытсва ради ответьте - какие достоинства имеет данная схема. Недостатков же, помимо указанных tru55, я могу накидать еще
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072196
Edkonst2008
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Вот чисто любопытсва ради ответьте - какие достоинства имеет данная схема. Недостатков же, помимо указанных tru55, я могу накидать еще

Единственный (IMHO) сомнительный плюс - каждая запись в БД вне зависимости от объекта имеет уникальный номер.
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072235
Рубик6
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
baracsНе понятно: как у вас сейчас ID объектов генерятся и, как будут генериться.
Зачем в каждой таблице auto_increment поле?

Сейчас обычным способом -- в каждой таблице с объектами есть поле ID, оно же PK, оно же auto_increment.

baracsЗачем в каждой таблице auto_increment поле?

Чтобы каждому объекту присваивался уникальный ID при вставке.

baracsОдна таблица == один класс объектов?


Да.

baracsИ вы хотите создать справочник классов?

Нет, скорее справочник объектов.
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072256
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рубик6Чтобы каждому объекту присваивался уникальный ID при вставке.А зачем?
Поищите в оракловом подфоруме топик про "один сиквенс на таблицу vs один сиквенс на все таблицы".
Насколько я помню, там убедительного плюса для второго варианта предложено не было.

Кстати, хинт. Чтобы вашем случае таблица не разрасталась - не делайте FK на нее из других таблиц (все равно смысла нет) и периодически удаляйте из нее все записи кроме самой последней. Это фактически получится эмуляция сиквенса в MySQL.
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072260
Рубик6
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Edkonst2008Вот чисто любопытсва ради ответьте - какие достоинства имеет данная схема. Недостатков же, помимо указанных tru55, я могу накидать еще

Накидайте, буду признателен.

SERG1257Единственный (IMHO) сомнительный плюс - каждая запись в БД вне зависимости от объекта имеет уникальный номер.


Да, это плюс, кроме того есть и другие причины.
Первая: есть необходимость помечать объекты как удаленные, это было бы удобно делать в этой таблице и не держать лишних записей в остальных.

Вторая: в таблицах с полями объектов нужно хранить несколько версий одного и того же объекта с одинаковым ID. Следовательно, этот ID не может быть PK в данной таблице и его нужно генерировать где-то еще. Введение единого справочника всех объектов решает проблему генерации ID для объектов. Если отказываться от него, прийдется делать для каждого типа объектов (а их много) отдельную таблицу, состоящую только из одних ID, чтобы присваивать их создаваемым объектам. Или существует более красивое решение?
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072434
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft Кстати, хинт. Чтобы вашем случае таблица не разрасталась - не делайте FK на нее из других таблиц (все равно смысла нет) и периодически удаляйте из нее все записи кроме самой последней. Это фактически получится эмуляция сиквенса в MySQL.
Не хинт, а способ:) Только зачем нужно создавать и удалять записи? Неужели это производительнее, чем одна запись? В соседнем топике на эту же тему утверждали, что хранение ид. в одной записи менее производительно, чем создание новых записей. Но у Вас то еще и удаление:)
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072469
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рубик6 Накидайте, буду признателен.Конкуренция на вставку, одна точка отказа (таблица заблокирована и работа всего приложения встала), дикое количество проверок для FK при необходимости удалять и т.д.
Рубик6 Первая: есть необходимость помечать объекты как удаленные, это было бы удобно делать в этой таблице и не держать лишних записей в остальных.Как лишних записей , может лишнего битового поля
Рубик6 Вторая: в таблицах с полями объектов нужно хранить несколько версий одного и того же объекта с одинаковым IDХранение версий в той же таблице далеко не единственный и совсем не самый лучший способ хранения истории.
Рубик6 Или существует более красивое решение? Но это уже совсем другой вопрос, лучше поищите по форуму.
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072798
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бредятинаmiksoft Кстати, хинт. Чтобы вашем случае таблица не разрасталась - не делайте FK на нее из других таблиц (все равно смысла нет) и периодически удаляйте из нее все записи кроме самой последней. Это фактически получится эмуляция сиквенса в MySQL.Не хинт, а способ:) Только зачем нужно создавать и удалять записи? Неужели это производительнее, чем одна запись? В соседнем топике на эту же тему утверждали, что хранение ид. в одной записи менее производительно, чем создание новых записей. Но у Вас то еще и удаление:)Этот хинт относился именно к auto_increment-ному полю в MySQL InnoDB. От одиночной записи с самостоятельно высчитываемым инкрементом отличается тем, что нет точки блокировки. Да и производительность самой операции, возможно, окажется выше, т.к. сокращается количество SQL-запросов. А удалять предыдущие записи можно не сразу, а во время меньшей нагрузки.
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37072973
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для таких целей используют GUID в каждой таблице и после создания записи записывают его в мастер таблицу
ПГШВ уникален - поэтому конфликтов не будет
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37073020
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftБредятинапропущено...
Не хинт, а способ:) Только зачем нужно создавать и удалять записи? Неужели это производительнее, чем одна запись? В соседнем топике на эту же тему утверждали, что хранение ид. в одной записи менее производительно, чем создание новых записей. Но у Вас то еще и удаление:)Этот хинт относился именно к auto_increment-ному полю в MySQL InnoDB. От одиночной записи с самостоятельно высчитываемым инкрементом отличается тем, что нет точки блокировки. Да и производительность самой операции, возможно, окажется выше, т.к. сокращается количество SQL-запросов. А удалять предыдущие записи можно не сразу, а во время меньшей нагрузки.
Это мы просто гадаем, к сожалению:) И точка блокировки есть, разве что на другом уровне. И создание/удаление записей по другому влияет на пространство памяти. Когда у кого-то появятся экспериментальные данные, учитывающие все факторы, мы может быть что-нибудь узнаем:)
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37073035
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БредятинаИ точка блокировки есть, разве что на другом уровне.Есть-то есть, но она значительно короче по длительности и не зависит от программиста, который свою блокировку может отпустить и через полчаса.
...
Рейтинг: 0 / 0
Хранение auto_increment поля в отдельной таблице
    #37073111
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftБредятинаИ точка блокировки есть, разве что на другом уровне.Есть-то есть, но она значительно короче по длительности и не зависит от программиста, который свою блокировку может отпустить и через полчаса.
Ну, "одна на всех" "функция извлечения ид." не может "отпустить свою блокировку" через полчаса. Так что, ни от каких программистов здесь ничего не зависит. К тому же, как мы уже знаем, приложения баз данных вообще не должны программироваться. Они должны проектироваться:)
...
Рейтинг: 0 / 0
15 сообщений из 15, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хранение auto_increment поля в отдельной таблице
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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