Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2017.01.15;
Скачать: [xml.tar.bz2];

Вниз

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

 
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;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.48 MB
Время: 0.046 c
15-1448570868
DayGaykin
2015-11-26 23:47
2017.01.15
Добавление зависимых записей.


2-1420137726
Боб
2015-01-01 21:42
2017.01.15
Загрузка аудиозаписей в VK


8-1238746691
igor666
2009-04-03 12:18
2017.01.15
Карта города.


2-1421904151
i2e
2015-01-22 08:22
2017.01.15
В MDI-приложении надо программно сделать окно активным


15-1454511393
pavelnk
2016-02-03 17:56
2017.01.15
Солнечная станция





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский