Что предпочесть id или самостоятельное формирование уникального ключа для таблицы

Имеется у меня таблица с большим количеством товара и от разных поставщиков.

Написал знакомому программисту, к способностям которого отношусь с уважением, поэтому решил посоветоваться с ним:
Не вижу необходимости в id - думаю от него отказаться, а вместо него использовать иное ключевое поле, например id поставщика товара + № пп товара. Соображения, но далеко не все: id практически не используется, кроме того после удаления предложения будут образовываться "дыры" - и какой в нем (данном поле) смысл ? Самое главное - вывод информации, используя индекс по id, применяться будет не так часто.

Получил ответ:
Вы усложняете. Проще сделать обычным образом через id (это поле всё равно заводится) и индексы по полям, по которым нужен быстрый поиск.

Его ответ меня не убедил (думаю, может быть неполным или он может ошибаться), поэтому решил обратиться за советом к знатокам:
• Действительно ли будет создаваться автоматически id ?
(Вообще-то реализовать свой уникальный ключ (ключи) не представляется сложной проблемой, наверное, основная цель затеи - зачем занимать (засорять) память, если даже не столько могу, сколько у меня и так будут уникальные ключи для каждой записи).
• Второй вопрос: скорость выборки: для id мне хватит 5-ти значного числа, а при формировании своего ключа число цифр увеличится, скажем до 8 знаков. И соответственно, хотя оба варианта и будут проиндексированы, но во втором случае соответственно "дыры" между записями будут заметно большими. (но и для id они также будут, причем будут постоянно увеличиваться разрывы между записями, хотя и не такими заметными)
Насколько это серьезный минус - т.е. скорость выборки с использованием индекса по ключу будет ли заметно отличаться от поиска по id ?

0

Сообщение от Usaga лишние индексные файлы не есть хорошо Это не лишний индекс. Во-первых, он кластерный. Во-вторых, он тебе гарантированно нужен.

В данном примере он может быть лишним (при наличии замены id) Не понимаю, для чего тогда нужен - речь идет об условном варианте: что у меня есть уникальный ключ вместо id каждой записи.

* Я не спорю или пытаюсь что-то доказать - для этого у меня нет знаний, а просто высказываю соображения

Сообщение от Usaga оторый можно будет использовать для разных целей (мин двух) Цель у него только одна - идентификация записи с быстрым поиском.

Когда писал о разных целях, имел в виду поле не id, а формируемое уникальное, по которому можно было бы получить:
- какую-либо определенную запись (карточку товара)
- группу записей по определенному признаку (принадлежность к поставщику)
т.е. данный индекс выполнял бы с успехом две функции (цели)

И, если по любому полю, имеющему индекс, "Скорость поиска по нему - логарифмическая, что на русском значит "очень быстро". " как Вы написали - то тогда и не понимаю причины, почему плохо в рамках оптимизации отказаться от id

0

далось тебе это id, нет такого понятия, есть понятие первичный ключ, а как он будет называться зависит от фантазии разработчика. хоть id, хоть папа римский, не рекомендую конечно так называть, гемморойно. дальше - самый удобный первичный ключ аутоинкрементный, заполняющийся без участия пользователя. если кровь из носу хочется усложнить себе жизнь и замедлить время создания записи, то пожалуйста - сам рассчитвай его значение, плюшек это не прибавит 100%, тем более не рассчитывай на ускороение доступа по ключу - обломится. вот и все. не чего мусолить одно и тоже. дырки его пугают, 100 раз ха-ха и даже хи-хи

0

Сообщение от 755 В данном примере он может быть лишним (при наличии замены id) Не понимаю, для чего тогда нужен - речь идет об условном варианте: что у меня есть уникальный ключ вместо id каждой записи.

Не нужно выдумывать ничего тут. Просто заведи ID (primary key) и всё. Я не понимаю, почему ты его боишься как чёрт ладана.

Я уже уставать начал от этой беседы. Будто бы пытаюсь убедить человека, что не надо всё делать через задницу, а он мне новые пути озвучивает, как можно всё усложнить, чтобы решить проблему, которую он на ходу придумывает...

0

Давайте подведу итог под данной темой.

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

А в процессе темы только и делаю, что даю ответы, либо объясняю недопонимания (это уже камень и в мой адрес, раз меня не могут понять)

Аватар, мне перед Вами постоянно приходится извиняться за то, что Вы меня не понимаете (а м.б. я Вас)
- id как термин использую вместо AUTO_INCREMENT как более короткий.
- дыры не пугают - они будут в любом случае, а о них упомянул только в связи со вторым вопросом.

Сообщение от Usaga Просто заведи ID (primary key) и всё. Я не понимаю, почему ты его боишься как чёрт ладана.

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

Добавлено через 17 минут
Gluck99, отдельное спасибо за Ваш подробный комментарий.

Некоторые комментарии По вопросу "бомба замедленного действия":
Вы и правы и нет, думаю надо рассматривать каждый конкретный случай в отдельности. (к слову у меня единица даже не товар, по крайней мере пока, а его привел просто как пример).
• возможный вариант: для товара под каждого поставщика создается своя запись (с учетом, например, того, что цены и не только они могут быть разными), А уже у них могут быть ссылки на общую часть (описание)
• ID-поставщика - величина не постоянная. => совершенно верно, ушел продавец, будут удалены и все записи, относящиеся к нему. (кстати, их надо будет удалять в любом случае, независимо от типа ключа: id или сформированный самостоятельно.
4) "Номер по порядку" - не говорил, что обязательно его использовать, а о возможности его использования при отсутствии сортировки - просто как дополнение для уникальности кода - а что такое id как не тот же порядковый номер (такой же бессмысленный во многих случаях)

Если хотите, можете не отвечать - в целом вы мне помогли, дав ряд советов.

0

Сообщение от 755 сравнительная скорость выборки (опять повторяюсь, но для понимания)

Сообщение от 755 на второй, хоть мне и пришлось его объяснять (повторять) мин еще два раза, так и не получил

Как это не получили ответа на второй вопрос? И я, и другие участники обсуждения дали на разные лады один и тот же ответ: никакого замедления при выпадении идентификаторов не будет (см. бинарные деревья, алгоритмы индексирования и т.д.). Тем более для вашего незначительного количества записей (не более 99'999) этот вопрос смехотворно ставить. Любые попытки поддерживать систему идентификаторов "без дырок" - это надевание штанов через голову. А использование естественного ключа против суррогатного (тот самый AUTO_INCREMENT) нуждается в очень хорошем, продуманном обосновании, базирующемся на чётких бизнес-правилах. Сам по себе естественный ключ - не хорошее и не плохое решение, плохи (я бы даже сказал нелепы) ваши аргументы в пользу естественного ключа. Чтобы использовать естественный ключ, нужно хорошо понимать те цели, которые вы с его помощью достигаете. Если вы не можете их нащупать и внятно изложить, вам естественный ключ не нужен, а нужен обычный суррогатный (он же AUTO_INCREMENT). И на этом всё по ключам.

К тому же вы упускаете ещё одну важную деталь, уже чисто техническую, имеющую отношение к программированию: а насколько архитектура вашей БД расположена к составлению простых и лаконичных запросов на выборку и обновление данных? И если вы примете неверное стратегическое решение по архитектуре БД сейчас, то в дальнейшем это приведёт к тому, что ваши запросы будут неоптимальными. А неоптимальный запрос, который вам придётся вынужденно писать - это падение производительности в разы, иногда на порядки, а не на 0.1% из-за какого-то не такого индекса. Вот о чём нужно реально думать, а не о дырках в массивах идентификаторов.

1

Благодарю Вас, Gluck99, за развернутый ответ.
Да, Usaga, упомянул о логарифмической скорости, но не смог понять, что это ответ на мой вопрос.

В таком случае не буду отнимать больше у всех время, и информация для размышления получена.

С огромной благодарностью за помощь.

0

В программировании существуют так называемые патенты программирования. Это условные правила. Зачастую они не несут никаких технических ограничений, но они облегчают разработку, сопровождение и понимает проекта.
Так и тут. Можно замутить свой ключ, обозвать его по другому но возможно когда через полгода кто то другой полезет в базу - он не поймет ваш замысел.
Например когда я использую форейн ключи я всегда в комментариях пишу - вот эту запись из таблицы мы удаляем сами, а записи из той таблицы удалятся/обнуляться сами так как привязаны через форейн ключи. Что бы через какое-то время не ломать голову как и что там работает.

1

Благодарю Вас за совет, Alex1126, с этим проблем не должно быть - написать руководство по БД несложно. Вот с структурой документации по клиентской части действительно не могу определиться. Даже для себя.

0

Сообщение от 755 Благодарю Вас за совет, Alex1126, с этим проблем не должно быть - написать руководство по БД несложно. Вот с структурой документации по клиентской части действительно не могу определиться. Даже для себя.

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

0

Сообщение от Alex1126 смысл использования стандартных решений именно в том что они понятны, условно, всем

А я как раз за нестандартные решения, чтобы они были понятны не всем, а только сообразительным

0

Сообщение от 755 А я как раз за нестандартные решения, чтобы они были понятны не всем, а только сообразительным

Так вы бы сразу озвучили, что ваша цель - не программирование, разработка и т.п., а составление головоломок и шарад в области IT. В таком случае понятно, почему у вас голова занята странными идеями, которые запутывают вопрос, а не решают его.

1

Сообщение от 755 но не смог понять, что это ответ на мой вопрос.

Я не смог понять потому, что вопроса нормального не услышал. Видел только реально шарады какие-то "угадай чёхачу".

0

Сообщение от Gluck99 А я как раз за нестандартные решения, чтобы они были понятны не всем, а только сообразительным Так вы бы сразу озвучили, что ваша цель - не программирование, разработка и т.п.,

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

А вообще хотел написать, что Вы в основном правы в моем отношении к id (хотя похоже это написал Usaga, ) вспомнил об этом не сразу (возможно что-то забылось с течением времени) - у меня было несколько случаев, когда даже не рассматривал возможность использования id:
• при реализации многоуровневого дерева категорий товаров (причем, программист, которому была интересна моя реализация, предложил свой вариант (общепринятый по его словам), но тоже без id.
• Другой же конкретный пример, как раз с использованием № пп (то, о чем рассуждали ранее) и что (о чем забыл), оказывается уже использовал ранее.
Реализовывал Справочник производителей товара (было примерно 1000 записей). Тогда только начинал осваивать php+mysql, поэтому естественно сформировал структуру:
id использовался в другой таблице (Таблица 1) как ссылка на производителя. И вот то самое отсутствие смысла id вынудило отказаться от его применения: нужно было, чтобы записи в таблице 1 сортировались по производителю, что было невозможно (если не ошибаюсь) при использовании id.
Возможно и даже быстрей всего, кто-то более умный предложит более изящное решение, но мое было таким:
1-4 символы = 1-4 символам названия Производителя (они охватывали примерно 90 % названий по уникальности), а 5-й как раз и стал № пп для формирования уникальности ключа для названий, у которых первые 4 символа совпадали.
На самом деле под номер для подстраховки использовал 2 символа - тот самый минус данного метода (ограничение на количество, о котором упоминал ранее).
В результате после замены поля id на kl в таблице 1 и формировании индекса по нему, все прекрасно сортировалось по названию.

Ps
Потом ради интереса, когда продумаю структуру таблиц, посмотрю, возможно даже в 90% случаях не увижу в нем смысла.

На этом все по этой теме, хотелось бы больше к ней не возвращаться

0

Сообщение от 755 id использовался в другой таблице (Таблица 1) как ссылка на производителя. И вот то самое отсутствие смысла id вынудило отказаться от его применения

Вы же сами себе противоречите. Если id использовался в другой таблице как ссылка на производителя (что правильно, так и надо делать), то непонятно, почему нужно отказываться от его применения? Потому что непонятно, каким образом вы делали связь с таблицей справочника в других таблицах, если у вас в таблице справочника нет id записи.

Сообщение от 755 нужно было, чтобы записи в таблице 1 сортировались по производителю, что было невозможно (если не ошибаюсь) при использовании id.

Одно ваше заявление абсурднее другого. У меня такое ощущение, что вы даже книгу из серии "SQL для чайников" не читали. В таких книгах чуть ли не на первых страницах пишут, как делать сортировку записей. И id тут совершенно ни при чём. То, что вы не хотите тратить время на чтение больших и толстых книг, понятно, но это не означает, что не надо читать вообще ничего.

Ещё замечу, что запрос на выборку без указания направления сортировки не гарантирует порядок записей. Поэтому в один прекрасный момент пользователь вашей чудо-системы может получить сюрприз.

Сообщение от 755 таким образом частично можно оценивать сообразительность

Сообразительность можно оценивать по-разному. Использование нестандартных решений там, где отлично работают проверенные паттерны, оптимальные и давно известные - это не сообразительность, а упрямство, которое, как говорил герой одного известного фильма, "первый признак тупости".
Сообразительный человек давно бы сообразил, что использование готовых решений - самый быстрый путь к достижению цели.

0

Сообщение от 755 Всего лишь хотел отметить (и то только для ответа, чтобы не быть невежливым), что таким образом частично можно оценивать сообразительность.

Не, ну это свинство какое-то. Ты сюда зашёл проблему решить свою или оценки проводить? Люди взялись тебе помогать, а ты оказывается, намеренно людям мозги полоскаешь?

Сообщение от 755 И вот то самое отсутствие смысла id вынудило отказаться от его применения: нужно было, чтобы записи в таблице 1 сортировались по производителю, что было невозможно (если не ошибаюсь) при использовании id.

Порядок записей в таблице неопределён. Всегда. Сортировки любые производятся при чтения таблицы.

Сообщение от 755 В результате после замены поля id на kl в таблице 1 и формировании индекса по нему, все прекрасно сортировалось по названию.

И какую практическую задачу ты таким костылём решил?..

0

0

Сообщение от Usaga Не, ну это свинство какое-то. Ты сюда зашёл проблему решить свою или оценки проводить?

Писал совсем не о том, а только о том, что не благодарность - плохая черта - только вчера обратил внимание - в одной теме человек получил совет (к слову именно от вас), а в ответ - ни спасибо ничего иного.

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

Просто в знак благодарности думал, м.б. мое решение окажется полезным для кого-либо. Как говорится - на нет, и суда нет.

Сообщение от Usaga Порядок записей в таблице неопределён. Всегда.

Тезис ложен. Не всегда, хотя и как правило.
Например, справочник стран или городов можно сразу сформировать по алфавиту. Или при хранении const js в таблице, о которых рассуждали только вчера в теме по js.

Сообщение от Usaga И какую практическую задачу ты таким костылём решил?.

Я же написал:

Сообщение от 755 нужно было, чтобы записи в таблице 1 сортировались по производителю,

Надо было добавить ... при выводе информации, но понадеялся на вашу сообразительность.


Gluck99, повторюсь, но если Вам не может быть интересна данная мысль, то и можно дальше не продолжать - об этом написал только в знак благодарности, для меня все это пройденный этап.
Есть
Мне нужно вывести на экран Таблицу 1 в формате:
название производителя (по алфавиту) + данные из таблицы

Какой можно применить индекс по Таблице 1 для вывода данных в таком (естественном, ибо по алфавиту) формате ? В случае использования для связи id

Добавлено через 9 минут

Сообщение от Аватар Не по теме: чайник возомнивший себя знатоком троллит всех подряд ))

Предлагаю не отвечать и завершить тему, а то уже пошли какие-то нездоровые комментарии. Ладно бы от сообразительного, а то еще и от того, кто половины вопросов не смог понять.

0

Сообщение от 755 Какой можно применить индекс по Таблице 1 для вывода данных в таком (естественном, ибо по алфавиту) формате ?

ни какой. упорядоченноcть выборки опредедяется только с помощью order by. упорядоченность без этого, хотя она часто и бывает, ни чем не гарантируется. а на том, на что нет гарантии, нельзя строить свои действия в этой сфере, иначе однаждя большой пшик будет, очень большой

1

Сообщение от 755 Какой можно применить индекс по Таблице 1 для вывода данных в таком (естественном, ибо по алфавиту) формате ? В случае использования для связи id

Я на ваш вопрос уже ответил заранее, в предыдущем своём сообщении. В запросе нужно добавить конструкцию ORDER BY.
Пример на ваших данных:
P.S. И всё-таки почитайте какой-нибудь букварь по SQL.

0

Спасибо за пример, Gluck99.

Думаю, на этом заканчиваем.
И конечно же не отказываюсь от чтения литературы. Добавлю, что на самом деле mysql изначально изучал по Никсону там было все просто, поэтому можно назвать и данную книгу букварем. А потом уже искал ответы на некоторые важные на мой взгляд вопросы.

0