Помещение ряда из таблицы в другую таблицу перед удалением

[qru]

Помещение ряда из таблицы в другую таблицу перед удалением

Добрый день.

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

Может быть у кого-то есть какая-то функция для этого или стандартное какое-то решение...

А то каждый раз приходится после создания соответствующей бекапной табилцы,
писать запросы сначала на получение (select) всех данных из основной таблицы для определенного id
а потом делать вставку (insert) в бекапную таблицу этих данных в правильном порядке и т.п.
А потом отдельным запросом уже удалять (delete) данные этого id из основной таблицы.

Может у кого-то есть более простое решение проблемы сохранения удаленного в mysql в отдельную таблицу?
Хотелось бы одной функцией или может даже запрос какой-то есть специальный в mysql.

Спасибо.

 

[newARTix]

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

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

 

[qru]

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

 

[phprus]

qru
Почитай про триггеры. MySQL и тоже поддерживает. Тогда можно будет обойтись средствами только СУБД и избежать вероятности забыть добавить такой функционал в какой-либо части приложения.

 

[newARTix]

qru
я бы сделал одну таблицу для всех с полями типа id, time, objecttype, data, и один класс/процедуру реализующий архивацию данных в сериализованном виде. Можно регулировать избыточность, сохранять связанные данные и т.п. Можно посмотреть как реализуется версионность объектов в разных CMS.

 

[iceman]

зачем сувать в другую таблицу? сделать поле "DELETED" типа date
если запись удалена, то - значение в нем - not null

 

[qru]

iceman - да можно просто сделать true false поле удалено или нет.. Но не хочу засорять таблицу.. да и переписывать функции все придется чтобы не выводили у тех у котрых стоит флажок что удалено.. В общем проще в отдельную таблицу... Мне кажется это правильнее

 

[newARTix]

iceman
я тоже так делал. Минусы:
1) нет централизованного управления версионностью. Каждый тип объектов, для каждой таблицы, по сути сам занимается этим делом. В большинстве случаев это не страшно, но иногда становится неудобным.
2) Таблица действительно очень быстро засоряется (у некоторых контент-менеджеров есть привычка жать "Save" после каждого добавленного предложения, несмотря на WYSIWYG), и, учитывая первую проблему, в рамках сайта становится не так-то просто эту проблему решить. Приходится вносить изменения в логику работы всех классов работающих таким образом.
На большинстве проектов опять же это не проблема, но на одном из достаточно нагруженных проектов, где используется несколько джойнов, с этим мусором поимел очень много проблем. В итоге пришлось просто снести все старые версии записей, чтобы хоть как-то снизить нагрузку на БД.

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

 

[iceman]

qru
а как же дата удаления?

newARTix
это не проблемы данного способа... твою первую проблему вообще не понял xD о чем ты?

 

[newARTix]

iceman
ну как же не проблемы, когда кол-во записей в таблице увеличивается на порядок? (имеется ввиду случай, когда в таблице хранится вся история изменений записи).
Первая проблема о том, что надо заморачиваться о реализации объектом этого функционала. И учитывать этот функционал практически в каждом методе объекта (выборка записи, выборка списка записей, выборка связанных записей, подсчет статистики, создание записи, удаление записи, сохранение записи, везде нужно помнить об этом гребаном флаге). Зачем?
Вообще ты когда-нибудь реализовывал данную схему? Просто я сделал на подобной наработке около 30 сайтов, и к 20ому начал понимать что это нихрена не удобно. И профита ноль.

 

[iceman]

о хоспади

-~{}~ 11.09.10 23:25:

прочитай про Вивьюхи

 

[newARTix]

iceman
про что?

 

[iceman]

views, Представление

 

[newARTix]

iceman
причем тут вьюхи?

 

[iceman]

> везде нужно помнить об этом гребаном флаге

-~{}~ 12.09.10 00:12:

его учитывать нужно только при селекте, при упдейте и инсерте он те никак не мешает, омг =)

 

[newARTix]

А, видимо речь о
http://en.wikipedia.org/wiki/View_(database)
ну почитаю, но не понимаю:
1) зачем все-таки городить этот огород, когда можно решить проблему гораздо проще, эффективнее и понятнее, на уровне приложения.
2) как это решит проблему производительности БД

-~{}~ 11.09.10 22:16:

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

-~{}~ 11.09.10 22:17:

И ты никак не отвечаешь на вопрос: ЗАЧЕМ? В чем преимущество этого метода?

-~{}~ 11.09.10 22:25:

Суть-то в чем. Функция версионности в большинстве случаев является опциональной, этаким приятным бонусом, ОЧЕНЬ РЕДКО используемой функцией. Нахрена нагружать ею модель объекта? Вот если это одно из основных свойств модели, что юзер постоянно переключается от версии к версии, тогда да имеет смысл делать так. Но в большинстве случаев это не надо.
Все-равно что Майкрософт вместо Корзины в своей ОС, сделало бы саму NTFS версионной.

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

 

[iceman]

> везде нужно помнить об этом гребаном флаге
select * from table where deleted is null =>
select * from table_v (вивьюха)

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

> как это решит проблему производительности БД
сменить СУБД, запихивать ночью данные в архивную таблицу, ну не знаю, придумать чонить

уть-то в чем. Функция версионности в большинстве случаев является опциональной, этаким приятным бонусом, ОЧЕНЬ РЕДКО используемой функцией. Нахрена нагружать ею модель объекта? Вот если это одно из основных свойств модели, что юзер постоянно переключается от версии к версии, тогда да имеет смысл делать так. Но в большинстве случаев это не надо.
Все-равно что Майкрософт вместо Корзины в своей ОС, сделало бы саму NTFS версионной.

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

его кто-нибудь понимает? какая нахрен модель объекта? чо за слово то такое? О_О

-~{}~ 12.09.10 01:22:

newARTix
какие еще классы, функции для БД? ололо?

-~{}~ 12.09.10 01:23:

qru
в чисто твоем примере - помогут триггер, на удаление... но вариант с отдельным полем deleted мне более по душе...

-~{}~ 12.09.10 01:36:

qru
и еще возьми за основу, не работать с таблицей на прямую, а работать с вивьюхой...

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

 

[newARTix]

iceman
удачи не завидую тем кто работает с твоим кодом и логикой размазанной не только по всему php коду, но еще и завязанному на особенности mysql впрочем, у всех свои представления о правильной архитектуре.

Объект - это инстанс класса. Класс так же можно назвать моделью объекта. Есть такая аббревиатура, MVC кажется Ололо?

> как это решит проблему производительности БД
сменить СУБД, запихивать ночью данные в архивную таблицу, ну не знаю, придумать чонить

ну эта фраза все объясняет

 

[zerkms]

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

newARTix
очень советую почитать первую главу "Developing Successful Oracle Applications" книги "Expert Oracle Database Architecture" от Т. Кайта (Thomas Kyte)

 

[iceman]

newARTix
я знаю что такое объект и класс, я так и не понял - откуда они тут появились.

приведи в пример, конкретно, чем обернулось для тебя добавление поля - deleted?

версионностью тут и не пахнет, версии будут если добавить parent_id но это уже совсем другая история...