Казалось бы, перечисленные ниже утверждения давно стали аксиомами, так ведь все время находятся лобачевские, которые полагают, что они без этих аксиом обойдутся. И каждый раз получают по лбу. Поэтому все-таки не пренебрегайте очевидным нижеизложенным.
– Любую систему придется изменять на всех этапах ее жизненного цикла.
– Любые обещания, что что-то не будет меняться, а уж тем более расти в объеме, никогда не выполняются.
– В больших системах не бывает маловероятных событий. Все, что может случиться, обязательно случится. Пользователи в России и Австралии обязательно нажмут на нужные кнопки одновременно, если вы этого не предусмотрели.
– Если одна и та же информация хранится в двух местах системы, то через неделю эксплуатации в этих местах будет разная информация.
– Нарушение известных правил проектирования с целью экономии времени разработки всегда приводит к увеличению времени разработки.
Я совсем не считаю, что свод правил проектирования вечен и неизменен, но если вы хотите какое-то из этих правил нарушить, то сначала поймите, почему оно появилось и какие суперпреимущества вам дает его отмена.
Еще одна очевидность, про которую забывают разработчики: удобство и скорость разработки, безусловно, важны, но все-таки система в итоге оценивается по ее потребительским свойствам. Если есть выбор, написать семь процедур или одну, но в последнем случае скорость отклика системы изменится с 0,5 с на 5 с, то писать надо семь процедур.
Впрочем, уверен, что этот раздел написал без толку. Похоже, это тоже одно из вечных правил.
Ниже приводится перечень грабель, на которые наступали и продолжают наступать настолько часто, что их рукоятки уже отполированы лбами проектировщиков.
Грабли-рекордсмены
Наверное, рукоятка таких грабель изготовлена из особо ценных и прочных пород дерева. Иначе непонятно, как они столько лет бьют по лбам горе-проектировщиков и до сих пор не сломались.
Сейчас мне кажется, что абсолютный запрет на любую семантическую интерпретацию идентификационных кодов мне внушили еще в детском саду. Вряд ли это так. Но по окончании института (хотя это произошло через пятнадцать лет после окончания детского сада, но уже тридцать лет назад) я точно знал, что в идентификационном коде не должно быть никакой семантики.
Никакой. НИКАКОЙ! НИКАКОЙ!!!Только циферки, которые однозначно определяют объект, и никакого другого смысла. Этому учили еще до появления классических работ Дейта и Кодда.
Но все-таки в каждом проекте у кого-нибудь начинает зудеть и чесаться.
«А давайте первая цифра кода у нас будет номером цеха, который выпускает изделие, вторая – номером отдела, который занимается продажей…» И что произойдет, когда у вас появится десятый цех или отдел? А когда изделие начнут в двух цехах собирать, какую цифру ставить? И как перевести производство из одного цеха в другой? Менять код изделия или запрещать перевод производства?
Да, а еще в код иногда засовывают буквы. А буква «А» есть как в русском алфавите, так и в латинском. И – увы! – для системы это РАЗНЫЕ буквы (хотя и не всегда можно это объяснить пользователю). Это создает много радости при ручном вводе новых идентификаторов и еще больше радости, если справочники и транзакции приходится загружать из другой системы. – Д. К.
«А давайте включим в id товара код группы и подгруппы…» А что вы будете делать, когда потребуется поменять код группы или подгруппы? Лопатить всю базу, разыскивая нужный id, и заменять его на другой? «А мы ничего не будем делать. Все равно в 90 % случаях группа и подгруппа будет верной». Вы этой мыслью с главбухом поделитесь. Ему очень понравится правильный расчет НДС с вероятностью 0,9. И не исключено, что на одного плохого проектировщика станет меньше.
«А давайте у нас id накладной и будет ее номером». Не давайте. Когда система встанет, накладные будут выписывать вручную, а потом в систему нужно будет ввести именно те номера, которые оказались на бумажных накладных, даже если это одинаковые номера. И накладные поставщиков неплохо завести в систему под теми номерами, под которыми они нам выданы.
И выучите, наконец, зазубрите, напишите на мониторе, сделайте татуировку на лбу: вводя любое информационное поле для любого объекта, можно ошибиться или передумать. Поэтому идентификационный код всегда—всегда!!! – должен генерироваться автоматически и не иметь никакой информационной нагрузки.
Читать дальше
Конец ознакомительного отрывка
Купить книгу