Сообщение Re[53]: В России опять напишут новый объектно-ориентированны от 11.04.2018 19:31
Изменено 11.04.2018 19:32 vdimas
Re[53]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>А что тут представлять???
S>
Какой кошмар. ))
А если в док-те порядка 250-ти строк?
На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.
S>И по-прежнему клиенту не обязательно знать идентификаторы заранее. Никаких тебе заморочек с над-реляционными кластерами.
Да это обычные заморочки с популярными алгоритмами распределения памяти, они открыты и общедоступны, бери да пользуяй.
Не вижу здесь сложностей.
В моих системах я делал так:
— заводил для редактируемых док-тов временные таблицы уровня пользователя;
— клиент редактирует, программа периодически пачками скидывает данные на сервак приложений (сохранять построчно-синхронно на трехзвенке на той технике было просто нереально — полусекундные спотыкания раздражают), сервак приложений обновляет данные во временных таблицах сервака базы;
— при потере связи клиента с сервером приложений или сервера приложений с базой данных ничего страшного не происходит (это как раз разрабатывалось в те времена, когда надёжной связи не существовало в принципе, даже локальной, бо тогда был коаксиал);
— для сохранения док-та делаются простые insert into из временных таблиц в обычные;
— при отмене док-та, т.е. удалении без сохранения, сервак приложений возвращает этот ID в список свободных.
Схема простая донельзя.
В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д. Т.е. сама задача не пропадает, просто переезжает с одного места в другое.
У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.
Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
Потому что самая первая версия, которая была без такой защиты, вызывала нарекания именно по этому вопросу, т.е. такая функциональность была реализована одной из первых, среди других "навороченных". ))
А мне тут в соседних топиках Cyberax втирает, что подобные трюки являются сверхсовременными и только Гугл их асилил.
S>А что тут представлять???
S>
S>begin tran
S>insert into master (name) values ('Первыйнах')
S>set @ID1 = SCOPE_IDENTITY()
S>insert into slave(masterId, Name) values (@ID1, 'Первый-1')
S>insert into slave(masterId, Name) values (@ID1, 'Первый-2')
S>insert into master (name) values ('Между первой и второй перерыва вовсе нет')
S>set @ID2 = SCOPE_IDENTITY()
S>insert into slave(masterId, Name) values (@ID2, 'Второй-1')
S>insert into slave(masterId, Name) values (@ID2, 'Второй-2')
S>commit tran
S>Какой кошмар. ))
А если в док-те порядка 250-ти строк?
На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.
S>И по-прежнему клиенту не обязательно знать идентификаторы заранее. Никаких тебе заморочек с над-реляционными кластерами.
Да это обычные заморочки с популярными алгоритмами распределения памяти, они открыты и общедоступны, бери да пользуяй.
Не вижу здесь сложностей.
В моих системах я делал так:
— заводил для редактируемых док-тов временные таблицы уровня пользователя;
— клиент редактирует, программа периодически пачками скидывает данные на сервак приложений (сохранять построчно-синхронно на трехзвенке на той технике было просто нереально — полусекундные спотыкания раздражают), сервак приложений обновляет данные во временных таблицах сервака базы;
— при потере связи клиента с сервером приложений или сервера приложений с базой данных ничего страшного не происходит (это как раз разрабатывалось в те времена, когда надёжной связи не существовало в принципе, даже локальной, бо тогда был коаксиал);
— для сохранения док-та делаются простые insert into из временных таблиц в обычные;
— при отмене док-та, т.е. удалении без сохранения, сервак приложений возвращает этот ID в список свободных.
Схема простая донельзя.
В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д. Т.е. сама задача не пропадает, просто переезжает с одного места в другое.
У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.
Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
Потому что самая первая версия, которая была без такой защиты, вызывала нарекания именно по этому вопросу, т.е. такая функциональность была реализована одной из первых, среди других "навороченных". ))
А мне тут в соседних топиках Cyberax втирает, что подобные трюки являются сверхсовременными и только Гугл их асилил.
Re[53]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>А что тут представлять???
S>
Какой кошмар. ))
А если в док-те порядка 250-ти строк?
На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.
S>И по-прежнему клиенту не обязательно знать идентификаторы заранее. Никаких тебе заморочек с над-реляционными кластерами.
Да это обычные заморочки с популярными алгоритмами распределения памяти, они открыты и общедоступны, бери да пользуй.
Не вижу здесь сложностей.
В моих системах я делал так:
— заводил для редактируемых док-тов временные таблицы уровня пользователя;
— клиент редактирует, программа периодически пачками скидывает данные на сервак приложений (сохранять построчно-синхронно на трехзвенке на той технике было просто нереально — полусекундные спотыкания раздражают), сервак приложений обновляет данные во временных таблицах сервака базы;
— при потере связи клиента с сервером приложений или сервера приложений с базой данных ничего страшного не происходит (это как раз разрабатывалось в те времена, когда надёжной связи не существовало в принципе, даже локальной, бо тогда был коаксиал);
— для сохранения док-та делаются простые insert into из временных таблиц в обычные;
— при отмене док-та, т.е. удалении без сохранения, сервак приложений возвращает этот ID в список свободных.
Схема простая донельзя.
В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д. Т.е. сама задача не пропадает, просто переезжает с одного места в другое.
У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.
Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
Потому что самая первая версия, которая была без такой защиты, вызывала нарекания именно по этому вопросу, т.е. такая функциональность была реализована одной из первых, среди других "навороченных". ))
А мне тут в соседних топиках Cyberax втирает, что подобные трюки являются сверхсовременными и только Гугл их асилил.
S>А что тут представлять???
S>
S>begin tran
S>insert into master (name) values ('Первыйнах')
S>set @ID1 = SCOPE_IDENTITY()
S>insert into slave(masterId, Name) values (@ID1, 'Первый-1')
S>insert into slave(masterId, Name) values (@ID1, 'Первый-2')
S>insert into master (name) values ('Между первой и второй перерыва вовсе нет')
S>set @ID2 = SCOPE_IDENTITY()
S>insert into slave(masterId, Name) values (@ID2, 'Второй-1')
S>insert into slave(masterId, Name) values (@ID2, 'Второй-2')
S>commit tran
S>Какой кошмар. ))
А если в док-те порядка 250-ти строк?
На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.
S>И по-прежнему клиенту не обязательно знать идентификаторы заранее. Никаких тебе заморочек с над-реляционными кластерами.
Да это обычные заморочки с популярными алгоритмами распределения памяти, они открыты и общедоступны, бери да пользуй.
Не вижу здесь сложностей.
В моих системах я делал так:
— заводил для редактируемых док-тов временные таблицы уровня пользователя;
— клиент редактирует, программа периодически пачками скидывает данные на сервак приложений (сохранять построчно-синхронно на трехзвенке на той технике было просто нереально — полусекундные спотыкания раздражают), сервак приложений обновляет данные во временных таблицах сервака базы;
— при потере связи клиента с сервером приложений или сервера приложений с базой данных ничего страшного не происходит (это как раз разрабатывалось в те времена, когда надёжной связи не существовало в принципе, даже локальной, бо тогда был коаксиал);
— для сохранения док-та делаются простые insert into из временных таблиц в обычные;
— при отмене док-та, т.е. удалении без сохранения, сервак приложений возвращает этот ID в список свободных.
Схема простая донельзя.
В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д. Т.е. сама задача не пропадает, просто переезжает с одного места в другое.
У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.
Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
Потому что самая первая версия, которая была без такой защиты, вызывала нарекания именно по этому вопросу, т.е. такая функциональность была реализована одной из первых, среди других "навороченных". ))
А мне тут в соседних топиках Cyberax втирает, что подобные трюки являются сверхсовременными и только Гугл их асилил.