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

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

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

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

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

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

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

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

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

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

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


Да.

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

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

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

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

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


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

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


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