Одна таблица или две?

← →
Некто © (2006-03-24 08:42) [0]

Имеется структура БД (точнее набросок структуры). В ней 2 почти одинаковые таблицы, например, "старая_вещь" и "новая_вещь". Разница в основном заключается в том, что первичные ключи в различны. Предполагается что, после какого либо периода новая вещь превратится в старую и её нужно будет переместить в таблицу старых вещей.
Стоит ли объединить эти таблицы и добавить в объединённую таблицу логическое поле, которое будет хранить флаг того, старая это вещь или новая? Как быть с ключами в случае объединения?

Предполагаемая СУБД MySQL 4.1. Если это имеет значение.

ЗЫ: Сознательно не поместил вопрос в раздел форума "Базы", т.к. это касается организации БД и к Delphi никакого отношения не имеет. :)

← →
Думкин © (2006-03-24 08:51) [1]

База описана не полностью. Что есть вещь? И т.п.
А все-таки - в базы бы.

← →
Некто © (2006-03-24 08:58) [2]

> База описана не полностью. Что есть вещь? И т.п.

Она (база) у меня только на бумажке нарисована. У меня ещё полное описание не созрело.

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

← →
Johnmen © (2006-03-24 09:13) [3]

Да, стОит объединить в одну.

← →
tesseract © (2006-03-24 09:14) [4]

а зачем тебе два первичных ключа?

> Как быть с ключами в случае объединения?

индексы не помогают?

> Представь одинаковые таблицы, у одной из которых первичный
> ключ составной,

Добавь в составной ключ ещё один индекс.

← →
Sergey13 © (2006-03-24 09:40) [5]

2Некто © (24.03.06 08:42)
>Как быть с ключами в случае объединения?
Если база у тебя пока только на бумаге, то какие проблемы ты тут ожидаешь? 8-)

← →
ivb2001 © (2006-03-24 10:10) [6]

Если использовать SQL, то прикинь по своей базе сам - нужны-ли индексы вообще? Может обойдешься SELECTом с обычными WHERE и ORDER BY?

← →
Sergey13 © (2006-03-24 10:12) [7]

2[6] ivb2001 © (24.03.06 10:10)
Иногда лучше жевать...

← →
Jeer © (2006-03-24 10:17) [8]

Sergey13 © (24.03.06 10:12) [7]

Некоторые даже этого не умеют:)
Этот ivb2001 © (24.03.06 10:10) [6] даже такие стрящные слова как SELECT и еще парочку, знает или слышал ?

> Некто © (24.03.06 08:42)

> Стоит ли объединить эти таблицы

Стоит.

← →
ivb2001 © (2006-03-24 12:50) [9]

Удалено модератором
Примечание: В песочницу

← →
Sergey13 © (2006-03-24 12:56) [10]

2 [9] ivb2001 © (24.03.06 12:50)
После прочтения моих брощюр я навсегда понял что SQL и индексы - это не взаимосключающие вещи. Они друг без друга практически жить не могут. Если в прочитанных тобой фолиантах говорится обратное - огласи их список, плиз.

← →
Jeer © (2006-03-24 12:57) [11]

ivb2001 © (24.03.06 12:50) [9]

И что, продвинутый ты наш, SQL и индексы несовместимы ?
Или ты не в курсе, что значит индекс для SQL-engine ?

Тогда - в библиотеку.

← →
Jeer © (2006-03-24 12:58) [12]

Sergey13 © (24.03.06 12:56) [10]

:)

← →
Sandman25 © (2006-03-24 13:03) [13]

Sergey13 © (24.03.06 12:56) [10]
Jeer © (24.03.06 12:57) [11]

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

← →
ivb2001 © (2006-03-24 13:10) [14]

Удалено модератором

← →
Sergey13 © (2006-03-24 13:11) [15]

2 [13] Sandman25 © (24.03.06 13:03)
Да все это понятно. Но у ivb2001 идет противопоставление SQL и индексов - против чего я лично и "восстал". Кроме того, как можно без индексов обеспечить целостность и непротиворечивость инфы в БД? Независимо от SQL/No_SQL?

← →
_inic (2006-03-24 13:44) [16]

Вообще, имхо, нельзя определенно сказать, объединять или нет, ибо суть вещи не раскрыта.
Может у новой вещи один набор аттрибутов, а у старой - другой.
В этом случае , опять имхо, оптимальнее "вести" две таблицы.

← →
Sergey13 © (2006-03-24 13:54) [17]

2[16] _inic (24.03.06 13:44)
>В этом случае , опять имхо, оптимальнее "вести" две таблицы.
Просто в этом случае, надо атрибуты хранить хитрее, чем просто набор полей в главной таблице.

← →
ivb2001 © (2006-03-24 13:57) [18]

Удалено модератором

← →
Sergey13 © (2006-03-24 14:04) [19]

2[18] ivb2001 © (24.03.06 13:57)
А как ключи в БД организованы - не напомнишь? Мне помнится (в брощюрке видел) - через индексы. И как с этим вяжется твое "нужны-ли индексы вообще"?

← →
ivb2001 © (2006-03-24 14:22) [20]

Удалено модератором

← →
ivb2001 © (2006-03-24 14:29) [21]

Удалено модератором

← →
Danilka © (2006-03-24 14:33) [22]

[20] ivb2001 © (24.03.06 14:22)
То-есть, в БД, в проектировании которых ты принимал участие, есть хотябы один форегинкей, по неиндексированым полям?
Просто интересно.

← →
Sergey13 © (2006-03-24 14:46) [23]

2[20] ivb2001 © (24.03.06 14:22)
>1.Только первичный! (!!!сюрприз, если не ошибаюсь )
Что, "только первичный"? А уникальный? В некоторых БД и внешний ключ без дополнительно индекса не сделаешь. А уж в главной таблице при этом он просто обязателен (ПК).

>Если бы я написал "нужны-ли будут тебе в этой таблице индексы вообще" ВАМ было бы понятнее?
Мне нет. Человек спрашивает про ключевые поля и есть ли смысл в объединении таблиц. А ты ему говоришь
>Если использовать SQL, то прикинь по своей базе сам - нужны-ли индексы вообще?
Т.е. я понял (и не только я), что если не использовать SQL, то индексы себя еще как то оправдывают. А вот если задействовать это чудо SQL, то они и нафик не нужны ваще. Кроме того этот ответ вообще не в контексте вопроса.

2[21] ivb2001 © (24.03.06 14:29)
>Вдогонку, пока меня опять дерьмом не облили.
>Сказав "Только первичный", имел ввиду ключ в таблице SQL
А что такое "таблица SQL"? 8-)

← →
Danilka © (2006-03-24 14:47) [24]

[20] ivb2001 © (24.03.06 14:22)
> 1.Только первичный! (!!!сюрприз, если не ошибаюсь )

Вообще-то, фраза из [6] предполагает вообще отказаться от индексов, в том числе и ПК, разве не так?
Думаецца, именно призыв к отказу от ПК и вызвал вполне прогнозируемую реакцию.

Удалено модератором

2[25] ivb2001 © (24.03.06 15:19)
Вот ведь упорный какой! 8-)
1. Как SQL позволяет выкинуть индексы вообще?
2. Если "Теория РЕКОМЕНДУЕТ" почему не создаешь? C SQL работаешь потому что?

Удалено модератором

Возвращаемся к

> ivb2001 © (24.03.06 10:10) [6]
>
> Если использовать SQL, то прикинь по своей базе сам - нужны-
> ли индексы вообще? Может обойдешься SELECTом с обычными
> WHERE и ORDER BY?

Разбираем:

>Если использовать SQL

В сабже и так оговорена СУБД MySQL - это уже подразумевает использование SQL-запросов.

>нужны ли индексы вообще?
SQL-engine и спрашивать не будет и так их создаст для primary key.
Впрочем, это относится к ограничению целостности, совместно со специально создаваемыми индексами unique constraint, unique index.

>SELECTом с обычными WHERE и ORDER BY?

А это уже непонимание важности индексов для SELECT с WHERE и ORDER BY.

Можно его не создавать, можно, но дальше начинается полный перебор или, например для MS SQL автоматическое создание статистики, но возрастают накладные расходы.

Индекс используется всегда, если:
- ссылается на предикат;
- индексируемый столбец не меняется функцией или арифм.операцией;

Эффективность индекса резко возрастает при создании конкатенированного индекса и выборки по этим же полям в том же порядке.

IMHO спорить о нужности дополнительных индексов бессмысленно по [0]. На бумаге, насколько я понимаю, было нарисовано 2 таблицы не связанные между собой. Предполагается вообще их объединить в одну... Нужны ли там доп индексы ? IMHO ХЗ будет наиболее верным ответом исходя из имеющихся данных :)

BTW Может быть в MySQL это и не так (как-то не довелось проверить) но в MSSQL таблица вполне себе может быть создана и без явного назначения первичного ключа

Удалено модератором

← →
ivb200_1 (2006-03-24 20:21) [31]

Удалено модератором
Примечание: Ишнорирование модератора

← →
ivb200_1 (2006-03-24 20:51) [32]

Удалено модератором

← →
ivb200_1 (2006-03-24 21:10) [33]

Удалено модератором

Читал где-то обсуждение...
Инет-магазин.. две таблички - корзина и заказы. Стоит ли объединять?

Тут фишка в чем "корзина" - маленькая табличка всегда (потому что данные там временные, лежат пока в заказ не перенесли), потому запросы по ней будут выполняться быстрее, чем в объединенной таблице с полем IsBasket.

← →
_uw_ (2006-03-25 09:55) [35]

Удалено модератором
Примечание: Обсуждение модерирования

Одна таблица или две? Найти похожие ветки