Я прав или нет? SQL - удалять записи по ID или по данным?

[Духовность™]

Я прав или нет? SQL - удалять записи по ID или по данным?

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

Сделал таблицу со столбцами id (primary, autoincrement), time (datetime), name (varchar)

И тут мне задают вопрос - а зачем тебе поле ID? Я отвечаю, что бы, например, удалить или редактировать запись. А мне отвечают - а что, по полю time нельзя это сделать? Ну и начали что-то там рассказывать про то, что "в случае удаления по ID тебе придётся делать дополнительные запросы" и т.д. Хотя, о каких доп. запросах может идти речь, когда мы априори при удалении записи знаем ID записи?

Так вот, прав я или нет? Мне всегда казалось, что разумнее удалять записи именно по идентификатору, а не по данным.

 

[Dovg]

Удалять надо то, что нужно удалять.
Если придется очистить таблицу - записи будешь по одной выдергивать и удалять?
Айди - уникален, он позволяет тебе изменить/удилить то, что нужно
а из твоего примера - несколько записей могут иметь одинаковое значение тайм, хотя все остальное будет разное

 

[dark-demon]

> Хотя, о каких доп. запросах может идти речь, когда мы априори при удалении записи знаем ID записи?

это надо было у них спросить

 

[fixxxer]

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

хотя не исключаю, что просто идиоты

 

[antson]

склоняюсь к мнению lfixxxer о провакационном вопросе.
Скорее всего пытались узнать твою подготовку в области проектирования баз данных. А имеено понятие об естественных и сурогатных ключах . так id - наиболее распространненый вариант сурогатного ключа , то хотели понять осмысленно ли ты его применяешь .
http://www.internet-technologies.ru/articles/article_271.htm

 

[magic]

Склонюсь к тому, что просто идиоты.

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

Запись удаляется по уникальному ключу. В данном случае, ключом, однозначно идентифицирующим запись, является автоинкремент.

 

[Vladimir_UA]

ТО: triumvirat

Так ты устроился на работу или нет?

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

 

[Фанат]

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

 

[fixxxer]

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

 

[Vladimir_UA]

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

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

 

[Krishna]

Ну и начали что-то там рассказывать про то, что "в случае удаления по ID тебе придётся делать дополнительные запросы" и т.д. Хотя, о каких доп. запросах может идти речь, когда мы априори при удалении записи знаем ID записи?

Так вот, прав я или нет? Мне всегда казалось, что разумнее удалять записи именно по идентификатору, а не по данным.

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

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

-~{}~ 17.09.07 18:11:

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

 

[Духовность™]

Krishna
подразумевается удаление записи из админ-интерфейса. никаких заморочек.

 

[Фанат]

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

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