Добавление зависимых записей.

← →
DayGaykin © (2015-11-26 23:47) [0]

1. Есть таблица квартир и таблица жителей.
2. В приложении есть таблица с квартирами. Кликаем по строке - открывается форма с параметрами квартиры.
3. На форме с параметрами квартиры располагается таблица с жителями. Из этой формы можно добавлять и удалять жителей.

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

Интересует опыт решения этой проблемы.

← →
Kerk © (2015-11-27 00:04) [1]

1) Генерируй ID квартиры способом отличным от AUTO_INCREMENT (что-то мне подсказывает, что у тебя MySQL, но не суть), тогда ты не будешь привязан к моменту вставки записи о квартире в БД. Будешь этот свой ID вручную указывать и при вставке самой квартиры, и при вставке жильцов.

2) В самом начале добавляешь в таблицу запись про новую квартиру, берешь его ID, работаешь. Если пользователь нажал "Отмена", откатываешь транзакцию и все.

← →
DayGaykin © (2015-11-27 00:12) [2]

> Kerk © (27.11.15 00:04) [1]

Да. И третий способ: добавляешь новых жильцов в память и после добавления квартиры в одной транзакции добавляешь и жильцов.

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

2) Держать открытой транзакцию долгое время не хочется - веб приложение. Добавить пустую квартиру тоже плохо, т.к. есть not null поля без значений по-умолчанию.

3) реализация клиента сложнее, но похоже придется так делать.

← →
Kerk © (2015-11-27 00:15) [3]

ну раз веб-приложение, то третий вариант конечно

← →
Сергей Суровцев © (2015-11-27 02:48) [4]

Есть 2 варианта. Либо генерировать ID отдельно, а не автоинкрементом, как ранее и говорилось. И это хороший вариант. Тогда транзакция будет короткой и после всего набора данных. Или не будет вообще.
Либо в базе ввести признак типа "квартира создается". Создать строку с ID, признак 0. После заполнения признак в 1. Но тогда надо раз в сутки такие строки чистить.

← →
sniknik © (2015-11-27 08:49) [5]

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

← →
Игорь Шевченко © (2015-11-27 11:44) [6]

> Интересует опыт решения этой проблемы.

Нету проблемы, потому что нету задачи.

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

Это - не задача, а попытка реализации

← →
virex(home) © (2015-11-27 11:51) [7]

> Добавляем новую квартиру и начинаем набивать жильцов.

ну вот как и пишет
> sniknik © (27.11.15 08:49) [5]

делим предложение на две части:
1. Добавляем новую квартиру
2. и начинаем набивать жильцов.

← →
Сергей Суровцев © (2015-11-27 13:41) [8]

>virex(home) © (27.11.15 11:51) [7]

Насколько я понял у него не должно происходить ситуации "квартира без жильцов". Поэтому при двухэтапном решении придется иногда чистить "мусор". А иначе все тривиально.

← →
ухты © (2015-11-27 13:59) [9]

> Добавить пустую квартиру тоже плохо, т.к. есть not null
> поля без значений по-умолчанию.
вы в квартире держите кол-во жильцов или подобное, может не стоит?

← →
DVM © (2015-11-27 14:14) [10]

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

Используй для ID квартиры GUID. Его можно вполне безопасно сгенерировать на клиенте без опасности получить коллизию с другим клиентом. Сгенерировал квартиру, нагенерил жильцов и только потом все и квартиру и жильцов скинул в базу. Бонусом получаем возможность сделать отмену добавления жильца или квартиры легко.

← →
MsGuns © (2015-11-27 14:15) [11]

Дай угадаю ! "База" на парадоксе или дбф ?

← →
MsGuns © (2015-11-27 14:17) [12]

Судя по "набиваем" и "кликаем" автор сабжа только осваивает азы. Может, книжку почитал бы какую-нибудь для начала ?
И эта.. что эта тема делает в "прочем"

← →
sniknik © (2015-11-27 14:17) [13]

> не должно происходить ситуации "квартира без жильцов"
а зачем смешивать разные объекты/сущности если следствие - проблема? это принципиально?

> придется иногда чистить "мусор".
мусор ли?
вот
> 3. На форме с параметрами квартиры располагается таблица с жителями.
т.е. квартиры нет, жители есть (как понял фразу, раз там целая таблица с жителями у несуществующей квартиры). получается, раз несвязанное в одну сторону мусор, то и в другую - без квартирные жители тоже, однако они есть. почему квартир не может быть? ведь оба варианта "жизненны".

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

← →
MsGuns © (2015-11-27 14:24) [14]

>и кстати у объектов кроме авто инкремента может быть и естественный ключ - адрес, номер паспорта/телефона/фио(?)/... по которым можно, не связку делать конечно (громоздко в отличие от числа), но проверять при вводе "а не дубль ли?".

Путь в тартар однако. Держать такие ключи, а тем более делать по ним сверку при "набивании" - заранее обрекать весь проект на глубокий провал и никчемность.
Адрес - вообще такая штука интересная :) Я уж молчу о том, что улицу могут и перименовать - у нас сейчас в Украине это очень модно :)

← →
DVM © (2015-11-27 14:28) [15]

Бывали ситуации с двумя квартирами с одним и тем же номером в одном и том же доме.
Так что на адрес лучше не полагаться.

← →
Игорь Шевченко © (2015-11-27 15:00) [16]

> Используй для ID квартиры GUID

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

Чтоб ты жил в квартире, где вместо номера GUID! :)

← →
Игорь Шевченко © (2015-11-27 15:02) [17]

> Бывали ситуации с двумя квартирами с одним и тем же номером
> в одном и том же доме.

Не могу удержаться:
http://habrahabr.ru/company/friifond/blog/271733/

← →
sniknik © (2015-11-27 15:48) [18]

> Держать такие ключи
зачем "держать" они естественным образом образуются из параметров, в дополнение к искусственному по автоинкременту/ets. для связок/работы по ним, во например для переименования.

> а тем более делать по ним сверку при "набивании"
и что вообще без проверок? что вбили то и внесли? (вспоминается старая конфигурация 1с торговли, из которой как то при проверке по 18 и более записей к примеру сыров с одним артикулом "повыковыривали"... "а то что то она тормозит, и считает неправильно" :))

← →
sniknik © (2015-11-27 15:53) [19]

> Так что на адрес лучше не полагаться.
а на что полагаться? вот ты вводишь данные и что, код кладр/фиас сразу введешь? допускаю, ты помнишь... большинство нет.

← →
DVM © (2015-11-27 16:10) [20]

> Игорь Шевченко © (27.11.15 15:00) [16]

Ну это же для внутреннего использования, видеть никто его не будет. Зато уникальный и легко сгенерировать.

> Чтоб ты жил в квартире, где вместо номера GUID! :)

Да я бы повесил, да циферки дорого обойдутся - много их надо :)

← →
Игорь Шевченко © (2015-11-27 16:38) [21]

DVM © (27.11.15 16:10) [20]

Вообще любой идентификатор легко сгенерировать, просто GUID хорош для глобальной уникальности, а для локальной он в большинстве случаев лишний и громоздкий.
Целая баталия была на этот счет:
http://www.sql.ru/forum/1165313/o-guid-identifikatorah

← →
DVM © (2015-11-27 17:54) [22]

> Игорь Шевченко © (27.11.15 16:38) [21]

> просто GUID хорош для глобальной уникальности

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

> а для локальной он в большинстве случаев лишний и громоздкий.

Локальные базы имеют свойство становиться глобальными и самое ужасное - сливаться из нескольких источников в одну глобальную. Вот тут то нам GUID и пригодится.
Громоздкость GUID в наше время не самый большой недостаток.

← →
Игорь Шевченко © (2015-11-27 18:03) [23]

DVM © (27.11.15 17:54) [22]

Я ссылку не просто так привел, почитай, мне не хочется дублировать оттуда аргументы. За 30 с лишним лет, что я имею дело с базамы данных, я GUID использовал только тогда, когда необходимо синхронизироваться с внешними разномастными системами.

← →
MsGuns © (2015-11-27 22:42) [24]

>sniknik ©

Коля, данные "набиваются" с первички. Вот в одном списке будет указан "пер. Лермонтова", а в другом "п/у Лермонтова", и оба раза будет правильно ! А адрес-то один и тот же :) Я уж молчу обо всех этих домах (150б, 150/б, 150-б, 150 крп б и т.д.)
Вообще самое правильное - это взять готовую базу улиц (а лучше и домов в т.ч.) из какого-нибудь эл.реестра, полагаю, что нынче он есть в любом даже самом вшивом городишке. Например, в бюро инвентаризации.

← →
MsGuns © (2015-11-27 22:43) [25]

Вообще, как обычно, ни темы проекта не озвучено, ни заказчика, но все дружно начинают "умно" советовать :)

← →
MsGuns © (2015-11-27 22:50) [26]

Еще важный момент, который нужно учитывать в подобных проектах. Регистр !
Тетеньки, которые будут "набивать", очень запросто забывают переключать языки, и поэтому возникают две РАЗНЫЕ улицы: Разина и Paзина (во втором слове две первые набраны на латинской раскладке).
Вообще, улицы, города, поселки и вообще географические названия необходимо не "набивать", а выбирать из списка. Как, кстати, делается на подавляющем большинстве нормальных сайтов.

← →
Труп Васи Доброго © (2015-11-30 12:47) [27]

Совсем не вижу проблемы, однако!
Две буквы "SP" принесут мир и гармонию автору.
Передай все данные в SP, она создаст квартиру, после вставки, получит её ID, создаст жильцов и понавтыкает их в квартиру. Делов-то на три копейки. И транзакцию держать не надо.

← →
Игорь Шевченко © (2015-11-30 19:05) [28]

Труп Васи Доброго © (30.11.15 12:47) [27]

С чего бы ? Операторы внутри хранимой процедуры магическим образом не становятся атомарным действием

← →
Труп Васи Доброго © (2015-11-30 22:04) [29]

Гм.. К какому предложению сей вопрос?
Насколько я понял волны своего миелофона, у товарища сейчас юзер имеет непосредственный доступ в таблицу. И вводит данные руками в режиме онлайн. При этом транзакция остаётся открытой в течении всего времени, пока тётя Маша топчет клаву. Я же предлагаю вводить данные в локальные формы, и только после того, как заполнены все поля вызвать SP, передать ей эти данные параметрами, дождаться от неё ОК или эррор (кстати, прописать жильцов в квартиру можно вообще в триггере AI, когда квартира уже гарантированно создана) и сделать комит. Итог - все счастливы, коллизий нет (практически), открытая транзакция не висит 15 минут.

← →
Игорь Шевченко © (2015-12-01 09:19) [30]

Труп Васи Доброго © (30.11.15 22:04) [29]

Я сильно извиняюсь, а какая разница, где выполнять операторы, создающие, генерирующие, заселяющие и так далее ? В хранимой процедуре на сервере или на клиенте ? Я разницы не вижу.

← →
sniknik © (2015-12-01 10:46) [31]

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

> При этом транзакция остаётся открытой
это твои домыслы, про конкретику реализации у него ничего нет.

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

← →
Труп Васи Доброго © (2015-12-01 11:00) [32]

> нет

Отвечу твоими словами: "про конкретику реализации у него ничего нет."

> это твои домыслы,

То есть ты правильно прочёл строку про миелофон.

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

Каким образом? Добрый человек попользует триггер BI, а не тупо даст команду на инсерт. Если этого (проверки) не делать, то какой в жизни смысл?

> без разделения объектов и их обработки логически, и добавления
> проверок при вводе, коллизии будут

Про то, что базу нужно сначала нормализовать, я не пишу, как о само собой разумеющемся факте.

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

← →
Игорь Шевченко © (2015-12-01 11:54) [33]

sniknik © (01.12.15 10:46) [31]

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

← →
Юрий Зотов © (2015-12-01 20:35) [34]

Присоединяюсь к [5].

← →
sniknik © (2015-12-02 02:07) [35]

> Проверки должны быть на уровне СУБД
а ты не сможешь их туда воткнуть... нет критериев проверки. вот как проверять правильность ввода адреса на уровне субд? произвольной строки фактически. выше там правильно писали адрес могут написать по разному... если позволить. поэтому нужно ввод формализовать, сделать меньше ввода больше выбора из готовых вариантов, в идеале в итоге получить уникальный ID типа кладр (на клиенте получить), а вот его уже можно проверять на уровне субд, не знаю уж на что, но можно придумать.

как субд проверит вот такое (введи в "Простой пример" - москва)
https://kladr-api.ru/examples

три новых москвы, и три деревни, вот выбрали одну из, откуда субд знает ее местоположение? а человек, если ему конечно там добавить инфы - регион/область (они есть в кладре из которого выпадающий список) выберет правильную... ну или ссзб. выбирает получаешь его код (он часть записи на выбор) которой и передаешь в базу.
не, оно конечно может быть достаточно и просто слова "д. москва" в базе, никому туда писем посылать не нужно, но тогда можно все автоматом заполнять - "noname/noadress" и не париться.

← →
Игорь Шевченко © (2015-12-02 10:19) [36]

sniknik © (02.12.15 02:07) [35]

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

← →
sniknik © (2015-12-02 12:48) [37]

> Ты споришь ради спора ?
не спорю, отвечаю... вот ты мне что-то персонально написал - по моим правилам хорошего тона (так воспитали) надо ответить. а раз пишешь "опровержения" значит чего-то в моем посте не понял - надо объяснить.
не понимаю почему воспринимаешь как спор.

sniknik © (02.12.15 12:48) [37]

Понятно, спасибо за ответ.

> вот как проверять правильность ввода адреса на уровне субд?

А правильность ввода адреса зависит, опять же, от задачи. Которая задача до сих пор неизвестна.

Дышым глубше, думаем дольше, а думать больно:)
...ну по факту не озвученой задачи:)

Сделал:
"добавляешь новых жильцов в память и после добавления квартиры в той же транзакции добавляешь и жильцов."

Вообще сабж похож на разовую работу: перевести с одного оператора по сбору платежей на другого.

> Делать надо правильно,

Как ты сделаешь - так и будет правильно

>DayGaykin © (04.12.15 02:16) [40]
>Сделал:
"добавляешь новых жильцов в память и после добавления квартиры в той же транзакции добавляешь и жильцов."

1. Что имеется в виду под "памятью" ?
2. Как добавляюся "квартиры", есть ли проверка на дубликаты в базе (кстати, это касается и жильцов") ?
3. Есть ли в модели "базы" справочники и как "прога" с ними работает ?
4. Существует ли вообще модель БД, а если существует, то каковы в ней сущности ?

Ну и наконец, главный вопрос: книжки не пробовал читать на тему ?

Я получил ответ еще на первой странице, за что спасибо. Все остальное: флуд, прокрастинация и мания величия.

>DayGaykin © (04.12.15 21:37) [45]
> Я получил ответ еще на первой странице, за что спасибо. Все остальное: флуд, прокрастинация и мания величия.

вы подгоняли логику под нелогичный интерфейс

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

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

> почему бы "окне" вновь созданной квартиры не добавлять жильцов
> из справочника жильцов?

Это долго. И объяснять потом придется, зачем сохранять квартиру, чтобы добавить жильцов. И что делать, если при вводе жильцов, этим самые жильцы передумали и теперь их вносить их не нужно?

Все понятно кроме того зачем тут

> добавляешь новых жильцов в память
, зачем и при чем тут память? Делаете на 1 странице/окне/диалоге квартиру и жильцов, в коде только смотрите новая или нет. Что то на голом месте перемудрено, впрочем говорили уже :)

Занимательная ветка.
Очень начинающий кулинар пытается добывать творог из вареников, а опытные повара советуют ему в выборе иструментов: рыбной вилки, мясницкого топора, десертной ложки и т.п.
:)

> DayGaykin © (06.12.15 10:31) [47]
>
> Это долго.

это норма (с) Малышева

> И объяснять потом придется, зачем сохранять квартиру, чтобы
> добавить жильцов.

сначала построили дом, затем в него заселяют жильцов
логично?

> И что делать, если при вводе жильцов, этим самые жильцы
> передумали и теперь их вносить их не нужно?

странный вопрос
если это произошло во время ввода - не вводить жильцов, если после ввода - удалить

Неужели когда я вырасту я стану таким же нудным и неуверенным в себе :( Опомнитесь.

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

хотя опыт - сын ошибок, удачи вам в будущем, в мрачном и нудном реверс-инжиниринге собственного кода

Добавление зависимых записей. Найти похожие ветки