Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Архив форумов ЦИТФорума
Море(!) вопросов - Море(!) ответов
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 
Как правильно задавать вопросы

Как учесть удаленные данные

 
Перейти:  
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Базы данных
Предыдущая тема :: Следующая тема  
Автор Сообщение
vns955



Зарегистрирован: 03.11.2005
Сообщения: 72

СообщениеДобавлено: Вт Июл 11 2006 00:40    Заголовок сообщения: Как учесть удаленные данные Ответить с цитатой

Всем здрасте
Народ, подскажите плз как мне решить такую задачу

Есть таблица договоров CONTRACT(id_contr - ключ, name, , ...), договора могут удаляться, но они должны попадать в некий архив и при необходимости пользаватель может просмотреть его.

У меня такой вариант:
соэдать таблицу CONTRACT_DEL(id_contr, date_del) кот. будет хранить номера удаленных контрактов и дату удаления

Хорош ли такой вариант? Есть ли более оптимальный?
Извините, если вопрос тривиален.
Спасибо
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Lamers



Зарегистрирован: 29.06.2006
Сообщения: 16

СообщениеДобавлено: Вт Июл 11 2006 10:22    Заголовок сообщения: Re: Как учесть удаленные данные Ответить с цитатой

Ну если будет необходимо просматривать удаленные контракты, то нужна будет вся инфа по нему, а не тока номер и дата удаления? Или ты хочешь заставить их по номеру определить, что это был за контракт?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Иван царевич



Зарегистрирован: 20.06.2006
Сообщения: 10

СообщениеДобавлено: Вт Июл 11 2006 14:09    Заголовок сообщения: Re: Как учесть удаленные данные Ответить с цитатой

vns955 писал(а):
Всем здрасте
Народ, подскажите плз как мне решить такую задачу

Есть таблица договоров CONTRACT(id_contr - ключ, name, , ...), договора могут удаляться, но они должны попадать в некий архив и при необходимости пользаватель может просмотреть его.

У меня такой вариант:
соэдать таблицу CONTRACT_DEL(id_contr, date_del) кот. будет хранить номера удаленных контрактов и дату удаления

Хорош ли такой вариант? Есть ли более оптимальный?
Извините, если вопрос тривиален.
Спасибо



Учитывая све вышесказанное не лучьше ли будет добавить поле
"CONTRACT_STATE"(или добавить параметр ''удален" если такое поле уже существует ) и выделять там удаленные контракты..
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
vladimir_kg



Зарегистрирован: 05.04.2006
Сообщения: 31

СообщениеДобавлено: Вт Июл 11 2006 14:46    Заголовок сообщения: Ответить с цитатой

Совершенно согласен с ЦАРЕВИЧЕМ, лучше добавить дополнительное поле, мороки меньше.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
grf



Зарегистрирован: 05.04.2005
Сообщения: 1242
Откуда: Москва

СообщениеДобавлено: Вт Июл 11 2006 15:29    Заголовок сообщения: Ответить с цитатой

небольшая поправка: тогда уж еще одно поле- дата, время удаления
Цитата:

У меня такой вариант:
соэдать таблицу CONTRACT_DEL(id_contr, date_del) кот. будет хранить номера удаленных контрактов и дату удаления

Wink
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
vns955



Зарегистрирован: 03.11.2005
Сообщения: 72

СообщениеДобавлено: Вт Июл 11 2006 15:46    Заголовок сообщения: Ответить с цитатой

Хорошо, но если у меня контрактов 1000, а удаленных 10, то получается я буду хранить 2 поля для всех (кроме 10) лишних.
В моей структуре в таблице CONTRACT_DEL я храню только номера удаленных, хотя конечно, предложенный вариант будет чуть быстрее работать...
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Lamers



Зарегистрирован: 29.06.2006
Сообщения: 16

СообщениеДобавлено: Вт Июл 11 2006 15:50    Заголовок сообщения: Ответить с цитатой

vns955 писал(а):
Хорошо, но если у меня контрактов 1000, а удаленных 10, то получается я буду хранить 2 поля для всех (кроме 10) лишних.
В моей структуре в таблице CONTRACT_DEL я храню только номера удаленных, хотя конечно, предложенный вариант будет чуть быстрее работать...

И что ты с этими номерами будешь делать? Смысл архива не совсем понятен?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
torpedouk



Зарегистрирован: 11.07.2006
Сообщения: 6

СообщениеДобавлено: Вт Июл 11 2006 16:33    Заголовок сообщения: Ответить с цитатой

vns955 писал(а):
Хорошо, но если у меня контрактов 1000, а удаленных 10, то получается я буду хранить 2 поля для всех (кроме 10) лишних.
В моей структуре в таблице CONTRACT_DEL я храню только номера удаленных, хотя конечно, предложенный вариант будет чуть быстрее работать...


В нормально построенной базе иногда из-за 1-2 записей делают поле.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
vns955



Зарегистрирован: 03.11.2005
Сообщения: 72

СообщениеДобавлено: Вт Июл 11 2006 17:40    Заголовок сообщения: Ответить с цитатой

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



Зарегистрирован: 29.06.2006
Сообщения: 16

СообщениеДобавлено: Вт Июл 11 2006 17:46    Заголовок сообщения: Ответить с цитатой

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

Ну так бы сразу Smile
Твоя таблица это самый лучший и оптимальный способ, хотя если посудить доп. поле тоже вариант, но тут есть заковырка:
так как данные удаляются сразу и переносятся в архив, то в какое место это поле запихивать Smile
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
EvilHamster



Зарегистрирован: 07.04.2006
Сообщения: 30
Откуда: www.ncstu.ru

СообщениеДобавлено: Чт Июл 13 2006 00:38    Заголовок сообщения: Ответить с цитатой

Зачем новая таблица? Зачем делать лишние движения по переносу записей в новую таблицу?

Самый оптимальный вариант было бы использовать дополнительное поле или два (первое - будет обозначать удаление, второе - на случай если необходима дата расторжения котракта).
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
grf



Зарегистрирован: 05.04.2005
Сообщения: 1242
Откуда: Москва

СообщениеДобавлено: Чт Июл 13 2006 09:06    Заголовок сообщения: Ответить с цитатой

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

2 Дополнительная таблица

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


Если у Вас соотношение действующих/просроченных договоров приблизительно одинаковое, я бы пошел по второму пути.
Если у вас Заметно Большая часть договоров действующих - то по второму.
Если Заметно большая часть договоров просроченных - то по первому.

Если записей в таблице не особо много то по первому, т.к. проще.
Если записей в таблице ПРОСТО УЖАСНО МНОГО, то исключительно по второму.

Если идти по второму пути на поиске сначала необходимо просматривать таблицу, где обнаружить договор более вероятно. Laughing Laughing
Wink
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
vns955



Зарегистрирован: 03.11.2005
Сообщения: 72

СообщениеДобавлено: Чт Июл 13 2006 11:46    Заголовок сообщения: Ответить с цитатой

EvilHamster писал(а):
Зачем новая таблица? Зачем делать лишние движения по переносу записей в новую таблицу?

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


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

ЗЫ
Записей у меня 500-600, удаленных будет не более 10
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
grf



Зарегистрирован: 05.04.2005
Сообщения: 1242
Откуда: Москва

СообщениеДобавлено: Чт Июл 13 2006 12:09    Заголовок сообщения: Ответить с цитатой

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

В итоге у тебя будет 2 таблицы,
первая оснавная со всеми данными
CONTRACT(id_contr - ключ, name, , ...)
Вторая, статус контракта, удален или нет
StatusContract(id_contr,status-удален, не удален{ проще всего использовать булевский тип, IMHO конечно},dateDel-дата удаления)

Тогда поиск проводишь по второй таблице, а оттуда по id вытягиваешь по необходимости всю инфу из первой таблицы.
Wink
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
vns955



Зарегистрирован: 03.11.2005
Сообщения: 72

СообщениеДобавлено: Чт Июл 13 2006 16:47    Заголовок сообщения: Ответить с цитатой

grf писал(а):
В принципе 500-600 записей это не много, так что делай как тебе удобно.

В итоге у тебя будет 2 таблицы,
первая оснавная со всеми данными
CONTRACT(id_contr - ключ, name, , ...)
Вторая, статус контракта, удален или нет
StatusContract(id_contr,status-удален, не удален{ проще всего использовать булевский тип, IMHO конечно},dateDel-дата удаления)
Wink


А зачем нужно status - я хотел там хранить только номера удаленных контрактов. Если мне надо знать удален он или нет - я делаю выборку из CONTRACT_DEL по полю id_contr с нужным номером. Если вернёт 0 записей, значит контракт не удален.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
EvilHamster



Зарегистрирован: 07.04.2006
Сообщения: 30
Откуда: www.ncstu.ru

СообщениеДобавлено: Чт Июл 13 2006 23:33    Заголовок сообщения: Ответить с цитатой

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

В конце концов, никто не брал на рассмотрение индексацию полей.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
grf



Зарегистрирован: 05.04.2005
Сообщения: 1242
Откуда: Москва

СообщениеДобавлено: Пт Июл 14 2006 08:31    Заголовок сообщения: Ответить с цитатой

Цитата:
А зачем нужно status - я хотел там хранить только номера удаленных контрактов.


Я рассматривал вариант, когда у тебя есть номер контракта, и тебе нужно узнать действующий он или нет, и если нет, то удален он или нет.
Таким образом ты просматриваешь только вторую, маленкую таблицу, что должно быть намного быстрее, и получаешь один из трех возможных ответов:
1. Контракт есть и дейтвует.
2. Контракт есть, но уже не действует.
3. Контракт не действует и уже полностью удален из системы.

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

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


EvilHamster, ты прав,
Цитата:
и все таки мне кажется создание второй таблицы неверным решением


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

Во второй таблице мы получем
поле id тип Word 2байта*600=1.2Кб
поле статус тип boolean 1бит*600/8=75б
поле дата тип DATA (не помню на вскидку скока весит 2 или 4 байта, возьмем по максимуму) 4байта*600=2.4Кб
Итого файл с таблицей будет весить 3.7Кб
Пусть со всеми рюшками и пр 4-5Кб, по силу любой, даже саой старой машине эпохе 286-386, или Бк-Спектрум Laughing Laughing
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Показать сообщения:   
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Базы данных Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2002 phpBB Group
Русская поддержка phpBB

 

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 6608306, ICQ 232284597
Пресс-релизы — pr@citforum.ru
Послать комментарий
Информация для авторов
This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2006 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...