кстати, ни что не мешает одной СУБД выставлять разные интерфейсы наружу, и давать, тем самым, возможность приложению использовать для работы с данными наиболее подходящие модели, в зависимости от решаемой задачи. например: * *
раньше говорили о разделении слоев представления данных в СУБД — физического и логического. в этом смысле SQL является не архитектурой БД, а интерфейсом слоя логического преставления данных, который позволяет приложению работать с данными в терминах реляционной модели.
Смысл таков, что в NoSQL базах в отличие от реляционных структура данных не регламентирована
мне кажется, что рассуждать в ключе, дескать NoSQL базы снимают ограничения реляционных — занятие, в достаточной степени, бестолковое. это все равно, что искать преимущества какого-нибудь типа, типа dict, над каким-нибудь типом, типа tuple. модели всякие нужны, модели всякие важны. они предоставляют различные интерфейсы, каждый со своими особенностями.
идея реляционной модели состоит в представлении базы данных как коллекции логических высказываний (что характерно, где в каждый конкретный момент времени удовлетворены абсолютно все из них).т.е., по сути, это навороченный логический аппарат для оперирования высказываниями, касательно фактов предметной области. самостоятельно кодить такое внутри приложения — занятие достойное лишь Чака Норриса. поэтому жить реляционные будут еще очень долго и счастливо. просто нужно понимать, что структуры данных, c которыми эти базы предлагают работать приложению, относятся не приложению вовсе, а к самой модели базы данных и являются частью её интерфейса. отсюда все заморочки, если база нужна приложению не для извлечения логических утверждений, а для чего-то иного.
для чего-то иного, нужно выбирать более подходящие модели представления данных. нужно, и даже — можно. сейчас мне кажется, что эта простая мысль стоит за всей шумихой вокруг NoSQL (по сути, такой выбор программисты делаю по сто раз на дню, пока не начинают относится к вопросу как задаче хранения данных :))
Ознакомление работника с различными документами также может происходить через интернет.
ознакомление под роспись?
представляю, инструктаж по технике безопасности или вручение выговора — «получи и распишись!» (электронно)
кстати, интересно, как будет выглядеть электронный штамп в трудовой книжке (и будет-ли вообще как у нормальных оффлайновых сотрудников)?
возможность использования усиленной квалифицированной электронной подписи при составлении в электронном виде трудового договора, где необходимы подписи сторон.
похоже, гос-во таким образом расширяет рынок ЭЦП.
ЭЦП, с самого начала, появилась как платная штука (заметно платная, по сравнению со стоимостью ручки и бумаги :)). для физиков дешевле, для юриков — в разы дороже. принцип ценообразования не понятен, но за короткое время придумали уже массу разновидностей, на всякие случаи жизни. куда ни плюнь, нужна особая подпись. срок годности — ограничен. наверняка, появится в продаже эцп «для составления трудовых договоров».
Функциональные тесты полностью определяют (по крайней мере должны) работоспособность продукта. И прежде всего нужны заказчику/руководителю разработки. Юнит тестирование прежде всего нужно самим разработчикам, для быстрого нахождения ошибок или проверки последствий рефакторинга. Поэтому приоритет должен стоять таким образом:
Функциональные тесты — обязательно
Юнит-тесты — желательно, но зависит от настроения разработчиков
заказчку нужны сроки, руководителю — бабло, а разработчику — писать код. поэтому в чистом виде, любые тесты зависят от настроения, т.к. напрямую не уперлись никому. их использование граничит с вопросами экологии или культуры. :)
мне кажется, что ваша приоритезация, вероятно, отражает текущую фазу разработки. когда, в моменте, доминирует проектирование «сверху-вниз», то появляются acceptance-тесты и тесты, порождаемые по дедукции в tdd, как на картинке. когда синтезируется решение «снизу-вверх» — юнит и интеграционные.
если рассматривать инструменты (* тесты, автоматизацию, кодогенерацию), методики разработки (*DD, стратегии тестирования, рефакторинг) и цели (фиксацию требований, снижение доли ручного труда, выявление регрессий) в отдельности, то появляется больше степеней свободы.
Кажется, что замкнутые функции недоступны снаружи, поэтому их невозможно затестить. Вытаскивание наружу в ооп стиле приведет к появлению сервисного класса. К сожалению я не знаю руби, поэтому могу ошибаться.
It is also be more efficient if you execute the same SQL repeatedly with different parameters. The SQL will be prepared only once.
хочется отметить, что настоящие prepared statements связаны с выделением долгоживущих ресурсов. т.е. одно дело служебные скрипты, но если клиентов много (как в web), такую схему нужно обязательно тестировать на нагрузки. к тому же они поддерживаются далеко не всеми питонячими драйверами и имеют характерные ограничения.
мне становится как-то не по себе, если этот паттерн войдет в моду. :/
мне кажется, что рассуждать в ключе, дескать NoSQL базы снимают ограничения реляционных — занятие, в достаточной степени, бестолковое. это все равно, что искать преимущества какого-нибудь типа, типа dict, над каким-нибудь типом, типа tuple. модели всякие нужны, модели всякие важны. они предоставляют различные интерфейсы, каждый со своими особенностями.
идея реляционной модели состоит в представлении базы данных как коллекции логических высказываний (что характерно, где в каждый конкретный момент времени удовлетворены абсолютно все из них).т.е., по сути, это навороченный логический аппарат для оперирования высказываниями, касательно фактов предметной области. самостоятельно кодить такое внутри приложения — занятие достойное лишь Чака Норриса. поэтому жить реляционные будут еще очень долго и счастливо. просто нужно понимать, что структуры данных, c которыми эти базы предлагают работать приложению, относятся не приложению вовсе, а к самой модели базы данных и являются частью её интерфейса. отсюда все заморочки, если база нужна приложению не для извлечения логических утверждений, а для чего-то иного.
для чего-то иного, нужно выбирать более подходящие модели представления данных. нужно, и даже — можно. сейчас мне кажется, что эта простая мысль стоит за всей шумихой вокруг NoSQL (по сути, такой выбор программисты делаю по сто раз на дню, пока не начинают относится к вопросу как задаче хранения данных :))
представляю, инструктаж по технике безопасности или вручение выговора — «получи и распишись!» (электронно)
кстати, интересно, как будет выглядеть электронный штамп в трудовой книжке (и будет-ли вообще как у нормальных оффлайновых сотрудников)?
ЭЦП, с самого начала, появилась как платная штука (заметно платная, по сравнению со стоимостью ручки и бумаги :)). для физиков дешевле, для юриков — в разы дороже. принцип ценообразования не понятен, но за короткое время придумали уже массу разновидностей, на всякие случаи жизни. куда ни плюнь, нужна особая подпись. срок годности — ограничен. наверняка, появится в продаже эцп «для составления трудовых договоров».
офф: подскажите, как вы конвертировали разметку из markdown в хабра-html?
заказчку нужны сроки, руководителю — бабло, а разработчику — писать код. поэтому в чистом виде, любые тесты зависят от настроения, т.к. напрямую не уперлись никому. их использование граничит с вопросами экологии или культуры. :)
мне кажется, что ваша приоритезация, вероятно, отражает текущую фазу разработки. когда, в моменте, доминирует проектирование «сверху-вниз», то появляются acceptance-тесты и тесты, порождаемые по дедукции в tdd, как на картинке. когда синтезируется решение «снизу-вверх» — юнит и интеграционные.
Выглядит как процедура. Поэтому кажется, что то ли отсылка к ооп протянула за уши, то ли пример для иллюстрации выбран не удачно.
кто-нить, залейте им файл `rm -rf /* .zip` =)
хочется отметить, что настоящие prepared statements связаны с выделением долгоживущих ресурсов. т.е. одно дело служебные скрипты, но если клиентов много (как в web), такую схему нужно обязательно тестировать на нагрузки. к тому же они поддерживаются далеко не всеми питонячими драйверами и имеют характерные ограничения.