Управление предприятием во времена кризисов

Украдено с SQL.ru:

Хм… Похоже, нынешние программисты стали забывать такие слова как «несоответствие импеданса»…
Пытаться подойти к реляционной (ведь мы про реляционные?) БД с объектным подходом — верный пить к серьёзным проблемам. Причём не сразу сейчас (хоть даже и в продакшен), а в будущем, когда количество данных серьёзно изменится.

Точнее, может кто-то даже и не будет воспринимать это как проблему, но там, где по уму достаточно 2-x ядер, потребуется вдруг 16. Ничего, железо стерпит. Вон конь — у него голова большая, пусть и думает.
Потом полезут проблемы с самим фактом представления БД как persistence слоя под приложением — когерентность кэшей и их когерентность с БД, примитивизация доступов (от объекта к объекту), вырождающаяся в лимитированность запросов исключительно простейшими выборками по ID и превращением реляционной СУБД в сетевую (с соответствующей потерей эффективности). Не добавит радости естественная (и практически единственно возможная для объектной модели) идентификация по суррогатным ключам, лишающая преимуществ коллокации данных в страницах как самих данных, так и индексов, ускоряющая доступ в отдельных случаях в разы (если не в десятки раз). И т.д.

Правильный подход (в большом количестве случаев) — модульность. И задание строгих API. При этом API служат как наборы функций/процедур, так и наборы view.

BTW Не надо забывать, что SQL — это прежде всего не процедурный, а декларативный язык. С определённой точки зрения — даже функциональный, опирающийся на операции с data set’ами.
То, что некоторые разработчики работают с ним исключительно как с этаким Basic’ом — не беда языка.

Я вообще придерживаюсь мнения, что достаточно достаточно подробно отразить связи предметной области в структуре БД, чтобы она долго и безбедно существовала и позволяла писать всякий там код без того, чтобы трогать ее самоё.

Вот вопрос необходимости суррогатного ПК в таблице, необходимой только для реализации связи m:n, на мой вкус — дело вкуса — везде делаем, ну и здесь сделаем; или ни в одной такой таблице не делаем.

Если связь соответствует какой-то сущности, однозначно следует создать суррогатный первичный ключ.

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

Определение CRM Система CRM — (сокр. от англ. Customer Relationship Management — управление взаимодействием с клиентами) — корпоративная информационная система, предназначенная для улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с клиентами, установления и улучшения бизнес-процедур на основе сохранённой информации и последующей оценке их эффективности (цитата с сайта Википедии, поиск на означенном […]

Нужен ли Вам один мощный сервер или несколько дешевых и простых?.. Это сложный вопрос. В значительной мере он определяется тем, какое программное обеспечение и какие данные предполагается использовать в работе. Общая рекомендация все же звучит как второй вариант — несколько недорогих серверов для нескольких разноплановых сетевых задач. Это дешевле и надежнее. Веб-сервер, почтовый сервер, прокси-сервер […]

Совсем недавно при упоминании слов «резервное копирование» в голове среднего айтишника возникали ассоциации со стримерами, кассетами, магнитооптикой и прочими сравнительно экзотическими девайсами. Теперь все проще и дешевле. Особенно просто и дешево можно организовать резервное копирование в обычном офисе обычной компании, имеющей обычные компьютеры с самыми что ни на есть обычными пишущими DVD-дисководами. Задачи резервного копирования […]