Удаление несвязанных записей

[Эдуард]

Удаление несвязанных записей

Как рационально организовать удаление несвязанных записей из связанных таблиц? Поясняю: К примеру, есть таблицы Клиенты и Заказы. По какой-то причине клиента удалили, а его заказы остались. Какой запрос удалит записи из таблицы Заказы, не имеющие Клиента. Таблицы связаны по полю client_id. В Access все просто. А здесь я профан. Так что буду благодарен.
Может есть аналогичная реализация аксессовского "автоматическое обновление связанных таблиц" и автоматическое "удаление несвязанных записей"?

 

[Апельсин]

1. есть foreign key constraints для InnoDB таблиц и соответственно ON UPDATE, ON DELETE. За подробностями в мануал.
2. если удаляют клиента, то удаляй сразу и его заказы.
3. время от времени чистить таблицы удаляя из заказов все те заказы, для которых клиента нет. Читать про multi-tables DELETE в мануале.
4. Ну и наконец последнее и на мой взгляд самое правильное: не надо ничего удалять. Запись просто помечается как удаленная.

 

[Verk]

Автор оригинала: Апельсин
4. Ну и наконец последнее и на мой взгляд самое правильное: не надо ничего удалять. Запись просто помечается как удаленная.

Не удалять с целью проведения централизованных периодических 'зачисток' или совсем-совсем не удалять ?

 

[Апельсин]

Все зависит от назначения системы. В общем случае ничего не удалять из системы.

 

[Vaik]

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

 

[Эдуард]

если удаляют клиента, то удаляй сразу и его заказы.

Так и происходит. Но в процессе тестирования иногда появляются несвязанные записи.

В общем случае ничего не удалять из системы.

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

Главное найти правильный момент для этого.

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

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

 

[Апельсин]

> Не совсем согласен, потому что не вижу смысла оставлять несвязанные записи, которые, на мой взгляд, ведут только к растранжириванию места на диске.

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

Хотя о специфике своей системы вы не сказали ни слова ..

 

[Эдуард]

Причем тут "несвязанные записи"?

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

 

[Crazy]

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

 

[Апельсин]

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

дык, тогда регулярные чистки.

на любой ублюдочной СУБД, не имеющей поддержки транзакций, контроль целостности БД

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

 

[Эдуард]

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

 

[tony2001]

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

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

 

[Эдуард]

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

 

[Апельсин]

Эдуард, все зависит от твоей системы и ее назначения. [off]В который раз я тебе пишу это?[/off] Если система серьезная то транзакции имеет смысл использовать и не мучаться со всякими удалениями и т.д., если нет, то тогда просто чистить. Кстати, что бы не надеятся на память админов подобную задачу можно просто запускать по крону, а заодно еще и делать таблице OPTIMIZE.

 

[Эдуард]

Вот это другое дело - ответ по теме.
Ну все ясно - спасибо - тема закрыта

 

[Sad Spirit]

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

Мысль абсолютно верная. Но чем меня не перестают удивлять поклонники MySQL, так это полнейшей неспособностью (боязнью?) сделать из неё вывод.

 

[Crazy]

Очень просто: есть два типа пользователей MySQL. Первую составляют те, кто пользуется этим по необходимости и при первой же возможности меняют СУБД. Вторую группу составляет религиозное сообщество "Фанаты MySQL". Понятно, что во втором случае говорить о доводах вообще нет смысла. Они и так знают, что MySQL круче всего -- это в священном писании записано.

 

[Эдуард]

есть два типа пользователей

Нет, Crazy, есть еще и третитй тип. К примеру, я не фанат. Мне достаточно знать, что MySQL одна из хороших систем. И, освоив ее, мне незачем искать другого, пока кто-нибудь не докажет, как я выиграл бы, если бы перешел, к примеру, на Postgre. А пока мускул решает мои, замечу, практические задачи, я не рыпаюсь...

 

[Sad Spirit]

Автор оригинала: Эдуард
И, освоив ее, мне незачем искать другого, пока кто-нибудь не докажет, как я выиграл бы, если бы перешел, к примеру, на Postgre. А пока мускул решает мои, замечу, практические задачи, я не рыпаюсь...

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

 

[Crazy]

Автор оригинала: Эдуард
И, освоив ее, мне незачем искать другого, пока кто-нибудь не докажет, как я выиграл бы, если бы перешел, к примеру, на Postgre.

Принципиальное отсутствие потерянных записей -- выигрышь?