Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2017.01.15;
Скачать: CL | DM;

Вниз

Правильная реализация   Найти похожие ветки 

 
Beck ©   (2016-02-20 10:41) [0]

Добрый день!

Подскажите как технически правильнее будет реализовать следующий пример. Имеется таблица Дом (House), и есть таблица Члены семьи (Person),
в одном доме могут проживать неограниченное количество людей (один ко многим). При редактировании членов семьи, у меня 2 варианта сохранения.

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

2. Вычислять дельту по 2 массивам членов семьи, массив членов семьи из таблицы и новый список членов семьи. Затем все чего нет в таблице, посадить, все что есть в таблице но нет в новом спике удалить из таблицы. А все что есть и в таблице и в новом списке, сделать Update.

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

Подскажите как правильнее сделать это ?


 
Ринсвинд ©   (2016-02-20 11:03) [1]

Давайте попробуем оценить недостатки обоих способов.

Недостаток полной перезаписи - время выполнения.

Недостаток "дифференциальной" записи - сложность реализации и, как следствие, повышенный риск ошибок. Представьте, сколько кода пришлось бы написать, чтобы сделать "дифференциальный" update, если бы жильцы были представлены не одной, а системой связанных таблиц.

Так что вам стоит подумать: насколько серьезна разница во времени между первым и вторым вариантом. Если разница не критична (а в случае с правкой 10 строк одной таблицы - семья ведь вряд ли будет больше - скорее всего так и есть), то, ИМХО, лучше использовать первый.


 
Inovet ©   (2016-02-20 11:24) [2]

Откуда такая постановка?


 
Inovet ©   (2016-02-20 11:25) [3]

И код какого дукумента? На паспорт не стоит надеяться.


 
Beck ©   (2016-02-20 11:36) [4]


> Ринсвинд ©   (20.02.16 11:03) [1]


Спасибо за развернутый ответ.


 
Beck ©   (2016-02-20 11:37) [5]


> И код какого дукумента? На паспорт не стоит надеяться.


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


 
Inovet ©   (2016-02-20 12:20) [6]

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


 
Beck ©   (2016-02-20 12:25) [7]


> Inovet ©   (20.02.16 12:20) [6]


Я проживаю не в России. У нас у каждого гражданина есть свой номер, который записан в паспорте. Он уникальный. И вместо ФИО, дата рождения, адрес и тд. пользователь вводит его номер, затем остальная информация подтягивается из базы, где все эти физ лица имеются. По этому идентификация пользователя для меня не проблема, для меня главное понять какой из 2 вариантов технически правильный.


 
Inovet ©   (2016-02-20 12:33) [8]

> [7] Beck ©   (20.02.16 12:25)
> какой из 2 вариантов технически правильный

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

И насчёт идентификации. Иностранцы не могут проживать?
- Такого не может быть.
- А если вот такая ситуация?
- Так это редко бывает.
Это к тому что помимо этого уникального номера нужен внутренний сурогатный или несурогатный ключ.Ну да бог с ним - с паспортом. Но я предупредил.


 
Inovet ©   (2016-02-20 12:50) [9]

Это я пока что не задал вопрос о истории проживания в доме.


 
Beck ©   (2016-02-20 13:11) [10]


> Это я пока что не задал вопрос о истории проживания в доме.


Об истории не подумал даже, по иностранцам пока не поступала задача. Но если учесть эти 2 факта, что необходимо хранить историю и разрешить добавлять иностранцев у кого нет номера. Тогда наверное оба моих варианта отпадают.


 
Кщд ©   (2016-02-20 13:23) [11]

ТС интересует, как технически правильнее, но не приводит никаких технических деталей
тем не менее, совсем не ясно, зачем ВСЕХ УДАЛЯТЬ, когда есть до боли простые операции insert/update/delete, которые чудеснейшим образом применяюся к записям, которые идентифицированы уникально


 
Beck ©   (2016-02-20 13:27) [12]

Побеседовав с вами пришел к следующему решению.

Помимо номера документа, я использую ID члена семьи. Если у члена семьи при сохранении имеется ID, значит происходит Update этой записи.

Если ID отсутствует, значит ищем по номеру документа, и Update если находим и Insert если не находим.

Если в базе есть люди, которых нет в новом списке, тогда проставляем им дату завершения, и таким образом отправляем его в архив.

Поправьте пожалуйста если ошибаюсь.


 
Beck ©   (2016-02-20 13:34) [13]


> Помимо номера документа, я использую ID члена семьи.


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


 
Труп Васи Доброго ©   (2016-02-20 13:41) [14]

Главный вопрос - нафига это вообще надо???
Если входящая таблица первична и непогрешима (ты же по ней делаешь однозначный апдейт), то нафига вообще таблица Person? Точнее правильный вопрос такой - нафига в этой таблице какие-либо данные из ГЛАВНОЙ таблицы, кроме ID?
Есть у тебя таблица домов - замечательно, есть таблица людей (в которой происходит непосредственное внесение изменений оператором) - отлично. Тебе нужна всего лишь таблица Person, содержащая ID_house, ID_people,Begin_date, End_date, ну и другие поля, относящиеся непосредственно к ПРОПИСКЕ в данном доме, но никак не к самому человеку. Тогда и таких глупостей не возникнет, как обновление всех жильцов.
Нормализация это называется


 
Кщд ©   (2016-02-20 13:41) [15]

нам отсюда не видно, что и насколько криво у вас реализовано
начните с указания БД


 
virex(home) ©   (2016-02-21 06:37) [16]

>Beck ©   (20.02.16 10:41) [0]

при редактировании члена семьи (имя, возраст и тд) редактироваться должен только член семьи.

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



Страницы: 1 вся ветка

Текущий архив: 2017.01.15;
Скачать: CL | DM;

Наверх




Память: 0.51 MB
Время: 0.022 c
15-1452881433
xayam
2016-01-15 21:10
2017.01.15
Приглашаю на шахматный турнир Delphi Masters 4 (2016)


15-1441176402
ВладОшин
2015-09-02 09:46
2017.01.15
Ищу Text to Speech, бесплатно, использовать буду из ПО на Delphi


15-1448011257
Сергей Суровцев
2015-11-20 12:20
2017.01.15
Вот и про нас вспомнили


15-1451560078
Kerk
2015-12-31 14:07
2017.01.15
С новым годом!


2-1426067911
aka
2015-03-11 12:58
2017.01.15
TObject через ссылку