Ну или как писали в комментах, если у тебя уникальное имя пользователя, то можно и его ключом делать

Правда, как по мне, неэффективо шопздц

Ну или как писали в комментах, если у тебя уникальное имя пользователя, то можно и его ключом делать

а вот он взял и опечатался и хочет изменить

Ну или как писали в комментах, если у тебя уникальное имя пользователя, то можно и его ключом делать

можно, но это не совсем удобно, т.к. у таблицы с пользователем обычно много связей

а вот он взял и опечатался и хочет изменить

Вооот. Поэтому лучше либо ид, либо юид

Да и хз я про производительность join'ов потом с текстовыми полями

а к примеру в таблице settings какойнить достаточно 1-2 текстовых колонки в качестве ключа + колонка значений. что-то типа module_id | key | value где все текст а module_id | key первичный ключ

Выбор столбцов, которые будут играть роль ключей, должен быть обоснован и предельно выверен, поскольку от них напрямую зависит производительность и целостность данных. Ключ должен быть в какой-то степени уникальным. Должна быть согласованность по типу данных для значения во всей схеме, а также чем ниже вероятность того, что это изменится в будущем, тем лучше. Можно ли проверить значение на соответствие стандарту (например, ISO)? Ключ должен быть как можно проще, чтобы можно было без трудностей использовать составные ключи. Это своего рода конвенции, которые нужно сформулировать при проектировании базы данных. Если требования впоследствии будут разрастаться, можно и нужно вносить изменения в структуру базы, чтобы поддерживать её в актуальном состоянии.

с составными ключами сплошной геморрой

меняешь значение одного из полей - придётся идти во все связанные таблицы и менять там

с нынешними размерами жёстких дисков нет никакой проблемы сделать инкрементный уникальный ид

и работать дальше по нему

для связующих таблиц в many-to-many тоже будешь инкремент совать?

для связующих таблиц в many-to-many тоже будешь инкремент совать?

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

ну вот пример таблицы настроек. для основного приложения и модулей к нему. зачем там автоинкремент?

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

у таблицы *сейчас* нет связей

и потом не будет

такая таблица не предполагает связей )

конечно, можно добавить id, когда они появятся

и потом не будет

никто не может этого гарантировать 100%

такая таблица не предполагает связей )

возможно, что так. как будет выглядеть апдейт?

и поэтому на всякий случай надо сделать? ))

и поэтому на всякий случай надо сделать? ))

лучше назови причину этого не делать

назови причину это делать ;D

унификация в рамках проекта -> проще ориентироваться -> меньше оверхэд в голове -> больше продуктивность -> профит

во всех базах всех фреймворокв и цмс, есть id в таблице настроек

или к примеру иногда нужна таблица просто ключ - значение

это поле не занимает много места, по нему есть индекс, не жрёт произвоидительность, не вижу причин не добавить его

зачем там ид? если в качестве ключа можно использовать тот самый ключ, который нужный

ключ будет текстовый?

само собой

ну тогда это тот же самый uid

допустим cron_last_run | date

просто его autoinc будет обеспечен другим путём

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

Всем привет) а насколько нужно декларировать возвращаемий тип функции? для чего ето нужно? может есть какието хорошие статьи на ету тему

Эти руки, матерь божья

http://pikabu.ru/story/iskusstvennyiy_intellekt_osvoil_parkur_5184118

Mchost.ru, в интернете есть промо код на 3 месяца халявного хостинга.

Обман, там сотку закидывать надо(

назови причину это делать ;D

вероятный профит от использования суррогатного ключа перекрывает недостатки его лишнего использования ... вот и вся причина

и как ты будешь его использовать? Скажи пожалуйста

сколько раз написать про апдейт?

Всем привет!

сколько раз написать про апдейт?

ты не догадываешься?

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

т.е. чтобы был )))

унификация в рамках проекта -> проще ориентироваться -> меньше оверхэд в голове -> больше продуктивность -> профит

этого мало?

следуя твоей логике в связующих таблицах тоже нужен автоинкремент, даже если он там не нужен

следует, нужен)

;D

выглядеть это будет так: category_post_id | category_id | post_id Индексы: category_post_id, category_id + post_id

ахахах ) когда-нибудь понадобится

возможно...

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

но не во всех таблицах нужен этот уникальный ид

в таблицу логов тоже автоинкремент будешь совать?

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

мы не договоримся ?

Такс, стоп @AlexKrasnov он говорит, что можно (нужно?) создавать таблицу без id?

Можно кикнуть его отсюда, плиз

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

Не плохой аргумент

Аналогичный аргумент: я использую только telegram и google chrome, можно выкинуть 90% ОС?

Аналогичный аргумент: я использую только telegram и google chrome, можно выкинуть 90% ОС?

аналогия неудачна, можно кикнуть его отсюда?

ERROR: S client not available

аналогия неудачна, можно кикнуть его отсюда?

Это говорит человек, который заявляет, что можно не фигачить id'ишники Чертовы сайтоклепаторы

ну вот к примеру создаешь ты очередь

@ilyalaba ты чет подозрительный

в бд... тож айдишники будешь делать?

А причем тут очередь?

эта очередь при нормальной посещалке забьется за пару месяцев

Что ты мелишь

Добрый день можете посоветовать видео курс по php

?

ну в каждой же таблице надо делать

автоинкремент

эта очередь при нормальной посещалке забьется за пару месяцев

Ясно понятно

народ веб-дизайнер это профессия ?

Иди читай что такое очереди и зачем они нужны

Добрый день можете посоветовать видео курс по php

Не понял

мой другговорит это хобби

Иди читай что такое очереди и зачем они нужны

очереди в том числе могут быть реализованы через бд

Дорогие друзья. Выручите вашего коллегу.

Ему вот надо срочно, в течении 2х часов собрать красивую lading page

очереди в том числе могут быть реализованы через бд

Они не могут быть реализованны через бд

Они могут хранится там

имеенно что красивую. Чтоб с паралаксом и минимумом ебатни

Они не могут быть реализованны через бд

да, хранится там. неверно выразился

Ему вот надо срочно, в течении 2х часов собрать красивую lading page

tilda.cc

в копмосере есть что такое? в дистирбутах

чтоб поставить чуть подправить и сразу полетело?

да, хранится там. неверно выразился

Но как у тебя база может забится?

Но как у тебя база может забится?

не база, а автоинкремент сраный

У тебя там будут хранится команды, которые будут запускаться через месяц?

ой иди нахер )

Если ты так боишься, то не храни их в базе, делов то