urn:lj:livejournal.com:atom1:about_zero about_zero about_zero 2009-11-06T17:34:58Z urn:lj:livejournal.com:atom1:about_zero:18825 2009-11-06T17:34:58Z 2009-11-06T17:34:58Z Сегодня таки убедился, что у меня на машине есть АБС :)) urn:lj:livejournal.com:atom1:about_zero:18575 2009-09-15T16:59:04Z 2009-09-15T16:59:04Z Очередные заметки на полях.<br />Итак, исходные данные. Сервер под управлением Win2003 Ent. Edition R2, 32 бита. 8 гиг оперативки. Oracle 10.2.0.3<br />Как уже понятно, ничего хорошего из такого сочетания получиться не может, ибо ограничение 2 гига на процесс не дает воспользоваться всем богатством.<br />Итак, что можно сделать. (В принципе, никаких откровений тут нет, все уже разжевано на sql.ru, тут просто компиляция фактов)<br />1. в boot.ini прописываем ключ /3GB<br />2. убеждаемся, что включено PAE<br />3. в реестр прописываем AWE_WINDOW_MEMORY. Есть рекомендации по конкретным значениям для различных конфигураций, я тупо поставил 1Гб (указывать надо в байтах, строковый параметр)<br />4. Начинаем мучать Oracle. В прниципе, проще всего сделать <br />create pfile from spfile;<br />далее, бэкапим на всякий случай этот файлик.<br />В текстовом варианте правим<br />use_indirect_data_buffers=true<br />db_block_buffers = &lt;сколько хотим памяти под кэш / размер страниццы&gt;<br /><br />Да, т.к. нам пришлось явно начать распределять SGA, про прелести жизни в виде sga_target можно забыть, поэтому нужно ручками прописать еще как минимум<br />shared_pool_size<br />streams_pool_size - нужен для репликации, impdp/expdp<br /><br />Еще не забываем про pga_agregate_target, она + все что не кэш должны влезть в 2(3) гига<br /><br />далее <br />shutdown immediate<br />create spfile from pfile;<br />startup<br /><br />И если все хорошо, то получаем экземпляр, который использует ресурсы нашего сервера как следует urn:lj:livejournal.com:atom1:about_zero:18413 2009-06-11T18:32:06Z 2009-06-11T18:32:06Z Просто чтобы в голове не держать.<br />№1 - alter table <div class='ljparseerror'>[<b>Error:</b> Irreparable invalid markup ('&lt;enable|disable&gt;') in entry. Owner must fix manually. Raw contents below.]<br /><br /><div style="width: 95%; overflow: auto">Просто чтобы в голове не держать.<br />№1 - alter table &lt;enable|disable&gt; row movement приводит к инвалидации всех пакетов, которые зависят от этой таблицы. А так как для shrink space нужно enable row movement, который по умолчанию выключен, получается больно и обидно :)<br /><br />№2 - Это уже скорее антипаттерн. Типичная задача - расчет витрин после окончания загрузки данных в хранилище. Наивная реализация - собрать вызовы всех процедур расчета в одном месте, и дергать этот мега-расчет одним махом. <br />Недостатки: сложно распарралелить расчет независимых витрин, если нет качественной обработки ошибок, сбой в одной из процедур валит весь расчет. Трудно запустить пересчет только одной витрины.<br />Так что похоже что гораздо оптимальнее - на каждую процедуру расчета - свой job, объединенные в sequence.</div></div> urn:lj:livejournal.com:atom1:about_zero:18105 2009-05-22T19:03:41Z 2009-05-22T19:03:41Z oracle 10.2.0.3<br />impdp схемы (на несколько гигов) с использованием remap_schema приводит к тормозам (более получаса) и падению процесса по out of memory (судя по всему в pga) в момент импорта статистики по таблицам. находил даже ссылку на баг в металинке... выход - указать exclude=statistics и потом ручками ее собрать после подъема дампа... urn:lj:livejournal.com:atom1:about_zero:17680 2009-05-20T16:13:53Z 2009-05-20T16:13:53Z "Эволюция одного процесса"<br /><br />Disclaimer<br />Все действующие лица выдуманы, все совпадения с реальностью случайны.<br /><br />- Декорации и действующие лица<br />Фирма А. Есть некоторая система, в которой работают пользователи. Доработки и исправления ошибок идут постоянно, без привязки к версиям.<br />Разработчик Р<br />Аналитик А<br />Менеджер проекта М<br />Добрый пользователь ДП<br />Злой пользователь ЗП<br /><br />- Действие 0. <br />ДП. "Ребята, у ват тут фигня какая-то. Посмотрите пожалуйстаЭ<br />Р. "Так, ага, тут у нас ошибочка. Сейчас мы ее поправим на рабочей базе"<br />М. Пребывает в блаженном неведении<br />Р. "Все, поправили, смотрите"<br />ДП. "Ага, спасибо. Но отвалилось теперь вот здесь"<br />Р. "Блин"<br />ЗП. "Ваша система говно! Ничего не работает! Я буду жаловаться!"<br /><br />- Действие 1. <br />М. "Так. Теперь на каждое изменение на рабочей базе вы будете давать на подпись мне бумажку, в которой будет написано, что и зачем вы хотите поменять"<br />Р. "Yes, sir!"<br />ДП. "Ребята, а сделайте вот такую вот фишку.."<br />Р. "Ага, сейчас, сделаем. Только одну бумажку напишу, и на подпись менеджеру"<br />Р. - М. "Вот, принес бумажку."<br />М. "А это что? А зачем? Надо? Ну ладно, делай..."<br />ДП. "Ребят, а вы меня не так поняли... Я то хотел с перламутровыми пуговицами..."<br />Р. "Блин"<br /><br />- Действие 2.<br />М. "Так, Теперь на любое изменение на бумажке должна быть подпись аналитика, и подпись пользователя, что они это протестировали, и согласны"<br />Р. "Yes, sir!"<br />Р. - М. "Вот, принес бумажку. И вот пользователь со всем согласен"<br />М. "Молодец, давай, выкладывай"<br />ЗП. "АААА!!! Вы опять все сломали!!! Я буду жаловаться!!!"<br />М. - Р. "Чё за фигня?"<br />Р. "Ну это, когда выкладывал, я там пару файлов с теста забыл перенести..."<br />М. "Все, процесс выкладывания на прод закрываем для разработчиков. А ну быстро забыл пароли! Теперь этим будут заниматься специально обученные люди"<br />Р. "Yes, sir"<br /><br />- Действие 3.<br />ДП. "Ребят, а у вас теперь фигня в другом месте вылезла"<br />Р. "Мда. Прохлопали"<br />М. "Так. Раздолбаи. Вредители. Вводим систему баллов. Принес бумажку - +1 балл, после бумажки что-то сломалось - тебе и тестеру по -3 балла. Уйдете в минуса - ай-яй-яй"<br />Р. - А. "А подпиши бумажку. Задача плевая, дело верняк"<br />А. "Ок. Неси еще пару простых, баллы зарабатывать нужно"<br /><br />- Действие 4.<br />Р. - М. "Вот, принес бумажку. Все подписи, красота"<br />М. "Угумм. Хммм. А как тестировали?"<br />Р. "Ну... Это А. тестировал, что то там проверили..."<br />А. "Ну... Это, там щелкнул, что то вылезло, тут что-то посчиталось..."<br />М. "Раздолбаи! Теперь к каждой бумажке будете готовить еще одну бумажку, где будет написан подробный тест-план"<br />Р. "Yes"<br /><br />- Действие 5.<br />М. "Таак. Это че? Где документация на код, я тебя спрашиваю! Я те дам самодокументирующийся код! Без документации на доработку никаких подписей!"<br />Р. (тяжело вздыхая) "..."<br /><br />Действие 6.<br />ДП. "Ребята, произошла срочная фигня, работа встала!!!"<br />Р. "Ага. понятно. Исправлений там на 5 минут. Через 4 часа все будет исправлено"<br />ДП "4 часа??? Почему так долго???"<br />Р. "Ну так это, бумажки писать, подписи собирать..."<br />Р. "А, сегодня же пятница. Ну тогда до понедельника, в пт. менеджер бумажки не подписывает"<br />ДП. рычит и превращается в ЗП. "ААА!!! У вас ничего не работает!!! Я буду жаловаться!!!"<br /><br />- Действие n.<br />ДП. "Ребят, а у вас вон там фигня."<br />Р. "Знаем, заводите задачу, пишите бумагу."<br />ДП. "У... Этим же надо заниматься. Ладно, обойдусь как нибудь без вас..."<br />ЗП. "ААА!!! У вас ничего не работает!!! Я буду жаловаться!!!"<br />Р1. - Р. "Слушай, а у нас ведь там фигня, и все скоро сломается"<br />Р. "Знаю. Но так ведь это надо задачу заводить, пробивать, бумажки писать... Ну нафиг. Сломается - починим" urn:lj:livejournal.com:atom1:about_zero:17550 2009-04-20T16:52:28Z 2009-04-20T16:52:28Z Вот. Завтра исполняется 3 недели с того "прекрасного" момента, как офис банка, в котором я имею честь сидеть на проекте, переехал в Химки. Пришлось из беззаботного пешехода переквалифицироваться в озабоченного водителя :) Ну а также сменить машинку, ибо регулярно ездить на азлыке удовольствия не доставяет. Это вам не раз в неделю на дачу потерпеть.<br />По времени доставка тела с утра к 8 часам занимает примерно минут 35-40, обратно минут 50. Не сильно хуже предыдущих мест работы. Если ехать общественным транспортом, выходим 1ч 40 мин.<br />Офис типа класса А+. Ага. По слухам, это первый опты Икеи в построении бизнес-центра. Так что бета-версия. Жрать ходим в Мегу через дорогу. 15-20 минут в одну сторону пешком. Ибо столовая внизу по слухам это дорого и не особо вкусно.<br />По общему заключению сотрудников, самое плохое в этом офисе - кресла. Блин, испанская инквизиция отдыхает.<br />Вот. Проект продолжается. Но желания работать на этом проекте, а главное силы воли уже практически не хватает. Все благодаря одному человеку. Вроде бы я и человек спокойный. Но вот нет, достало конкретно. Жаль, но похоже надо будет стряхнуть пыль, освежить в памяти боевые заслуги, и оглядеться вокруг себя. Жаль конечно фирму, она не виновата в том, что один из клиентов неадекватен, но не уверен, что смогу добиться перевода на другой проект. Да и хочется ли мне этого? В общем, хотя говорят и кризис на дворе, но ситуация меня конкретно заебала.<br /><br />Ну и напоследок маленькое напоминание самому себе. мониторить базу и состояние объектов на валидность надо постоянно. Первое, что должен сделать правильный админ или DBA - настроить полный мониторинг системы под себя. Надо будет собрать воедино пачку недоделанных своих скриптов, и привести их в порядок. А то надежды, что тут заработает система мониторинга, как то призрачны. Спасение утопающих - дело рук самих утопающих :) urn:lj:livejournal.com:atom1:about_zero:17072 2009-02-18T19:17:21Z 2009-02-18T19:17:21Z Вот, если предыдущий пост был про прослеживание взаимосвязей "культурным" путем, этот про археологические раскопки :) <br />Была тут недавно дискуссия на тему, чем кошернее собирать витрины в хранилище - ETL средствами, или средствами самой СУБД. После прослеживания путей растекания данных по хранилищу без участия документации, должен заметить, что у сборки средствами СУБД, есть один большой плюс - легко прослеживаются зависимости и преобразования. Чего не скажешь о ETL, который по сути своей - черный ящик, и автоматизированной обработке поддается весьма плохо, если не сказать отвратительно. Есть конечно исключения, типа SASa, где весь код можно выгрузить и просмотреть, но ведь у нас и не SAS используется :(<br />ЗЫ: На железный аргумент - а надо писать документацию в полном объеме, мне ответить нечего :) Я полностью согласен, что лучше быть богатым и здоровым :) urn:lj:livejournal.com:atom1:about_zero:16812 2009-02-18T19:07:50Z 2009-02-18T19:07:50Z Прорабатывая очередную фичу, столкнулся с необходимостью четкой трассировки требований. Это при том что никаких требований как документов у нас на проекте нет и отродясь не было :)<br />А в идеале хочется ткнуть пальцем в поле БД, и сразу получить, где, для чего оно нужно и кому понадобилось. Но это конечно уже совсем фантастика. <br />Похоже, надо будет поднять вопрос о том, что постановок и спецификаций недостаточно. Нужно внедрять полноценное управление требованиями. А то каменный век какой-то.<br />Остается понять, какую литературу почитать на эту тему, чтобы быть в курсе, до чего дошла современная прогрессивная мысль :) urn:lj:livejournal.com:atom1:about_zero:16436 2009-02-05T19:08:11Z 2009-02-05T19:08:11Z Копался тут с одной базой, которой внезапно стало плохо... Там много всего, но одно уж очень хочется подчеркнуть, ибо сталкивался уже неоднократно. Любой вызов функции в SQL запросе - полусгнившая бомба замедленного действия. Может и не выстрелить, но скорей всего рванет так что мало не покажется. Причем потенциальной засады, если анализируешь только план выполнения запроса, обычно и не видно, т.к. стоимость ее выполнения там не показана... Нужно гнать через trace/tkprof, там всплывает много интересного :) Помню один клинический случай - результат сравнения результатов выполнения функций был условием join'a. На совсем небольшой базе функция успел вызваться за короткий промежуток времени 1 500 000 раз :) Сервер наверное ее уже в лицо узнавал :)<br />Так что господа - абстракция конечно вещь хорошая, но если есть возможность преобразовать в подзапрос, а еще лучше, тупо присоеденить еще одну табличку, сделайте это. Сервер вам спасибо скажет :) urn:lj:livejournal.com:atom1:about_zero:16307 2009-02-01T08:44:29Z 2009-02-01T08:44:29Z Решил тут я выкачать архив своей почты с gmail на свой локальный винт. Выкачал. И вот в процессе разгребания почты за 4 года, подумалось, а имеет ли вообще информация в архиве хоть какую-то ценность для меня? И вообще, пойдя дальше, что в информационном потоке, который ежедневно протекает сквозь нас, имеет ценность, которая не девальвирует через неделю?<br />К сожалению (а может быть и к счастью), никак у меня не получается консолидировать всю проходящую через меня информацию в одной точке. Да хотя бы потому что используется несколько компьютеров, они меняются, меняются места работы... И вот такого, чтобы собрать почту, переписку по IM, все закладки, ebooks, заметки, куски кода в одном месте - ну не получается. Хотя можно конечно, если поставить себе такую цель.<br />А теперь возник вопрос - да и стоит ли консолидация и сохранение каких-либо усилий?<br />Особенно если рассматривать это не на короткой перспективе, например год, а посмотреть издалека, что из информации, которая лежит сейчас, потребуется через 2-3 года? Или же что из информации, которую я собирал 2-3 года назад, сейчас нужно мне? Похоже, что НИЧЕГО.<br />Технологии меняются, личные архивы используются только при приступах ностальгии.<br />Действительно важные данные должны находиться в голове. Понимание концепций, опыт, ключевые слова. А кратковременный мусор периодически вымывается, ну и фиг с ним. <br />В накоплении информации очень много субъективного, иногда она ощущается как вещь, с которой жалко расстаться. Но думаю что возможно. Достаточно провести мысленный эксперимент. Представьте, что вы начинаете новую жизнь. Новая работа, с чистым компом, домашний комп отформатирован, логины и пароли на все сервисы забыты (почта, аська, букмарки, ...), мобильник выкинут. Все, информация только та, что есть в голове. Наступила ли катастрофа? Надеюсь что нет.<br /><br />ЗЫ: Пока писал, вспомнил про архив фотографий. Дело конечно приятное, рассматривать фотки из отпуска 4 года назад, но вот честно, имхо все эти просмотры нужны только если пришли гости, и их нечем занять до подачи горячего :)) urn:lj:livejournal.com:atom1:about_zero:16090 2008-12-17T04:50:46Z 2008-12-17T04:50:46Z <a href="http://blog.not-a-kernel-guy.com/2008/12/16/395">http://blog.not-a-kernel-guy.com/2008/12/16/395</a><br />а я тут блин понимаешь переживаю над дуростью нашего ББ... По сравнению с гениальными идеями по ссылке это так, фантики... Ну подумаешь новая система именования объектов, когда проект уже на саппорте... будем писать tzx101_operation.cop_pk вместо существующего operation.op_id, и так во всем... Пох... И Нах... Даешь другой проект... уж лучше кипящий бардак, но где можно взять ответственность на себя и делать так, как считаешь нужным без такой опеки...<br />все, взмахнули рукой и расслабились...<br />боролся тут с забавным глюком... 2 сервера, почти похожих. на обоих стоит websphere, из-под которой запускается batch через runtime.exec<br />Так вот, на одном из серверов, при запуске одного специфичного exe, ничего не происходило, в отличии от второго, где все отрабатывало замечательно<br />первое. товарищи, вычитка выходных потоков дочернего процесса обязательна... а то понимаешь ли, подвисает процесс, ждет когда буфер почистят... Причем до какого то объема batch файла это незаметно (если не стоит echo off), а потом начинается...<br />и второе. надежнее формировать переменные окружения самому, в batch файле, потому как неизвестно, откуда и как вас будут запускать... потому что пришлось идти через straceNT, чтобы понять, что exe сваливается с exception (код забыл), когда не может найти какую-то dll... Вот почему на одном сервере находит, а на другом нет - хз, параметры запуска я сравнивал... прописал %PATH%, и успокоился... urn:lj:livejournal.com:atom1:about_zero:14954 2008-10-27T11:30:49Z 2008-10-27T11:30:49Z Развлекаюсь с небольшим симпатичным дистрибутивом. CRUX. Инициализация в BSD стиле, порты опять почти как в FreeBSD. При установке минимум, далее все ручками.<br /><br />Установка ничем особым не отличается для дистрибутивов такого направления, загрузка с boot cd, разметка диска, chroot на размеченный диск, первоначальная настройка rc.conf и сетки, сборка своего ядра, установка lilo/grub, перезагрузка...<br />Если не угадали с модулями ядра, то повторный процесс :)<br /><br />Не забыть сразу в /etc/ports добавить contrib, gnome, kde, xfce репозитории портов, список на сайте<br /><br />ports -u чем раньше тем лучше обновить дерево портов<br />prt-get diff разница между версией в port и установленной<br />prt-get sysup махом все обновить<br />prt-get depinst <package> - это чтобы порты сразу с зависимостями<br /><br />как обустрою рабочую среду, продолжение следует... urn:lj:livejournal.com:atom1:about_zero:13715 2008-08-09T11:18:25Z 2008-08-09T11:18:25Z "Когда в руках молоток, все вокруг кажется гвоздями"...<br />А вот когда в руках совковая лопата... urn:lj:livejournal.com:atom1:about_zero:13517 2008-06-20T15:13:55Z 2008-06-20T15:13:55Z Интересно, каково было бы Гераклу, если бы подвиг по вычистке Авгиевых конюшен ему пришлось бы повторять постоянно, вместо остальных 11ти подвигов?<br /><br />NB. а не пора ли вам сударь, обновить свой рекламный щит и встать у дороги? urn:lj:livejournal.com:atom1:about_zero:13256 2008-03-26T18:31:37Z 2008-03-26T18:31:37Z - Здравствуйте, я бы хотел заказать у вас садовую скамейку. Знаете, обычную такую, пара досок поперек, и спинка.<br />- Замечательно, что вы обратились именно к нам. Давайте, мы разработаем чертежи скамейки, приходите через неделю.<br />... прошла неделя...<br />- Здравствуйте, я насчет скамейки...<br />- Замечательно что вы пришли. Смотрите, у нас получился замечательный диван в викторианском стиле. Сейчас мы заняты тем, что рассчитываем толщину пуленепробиваемого стекла, стена из которого будет окружать ваш диван.<br />- Э... минуточку, мне нужна обычная садовая скамейка, ничего более...<br />- Мы все понимаем, не волнуйтесь. Вот, не могли бы вы взглянуть на эту электрическую схему? Она позволяет вам дистанционно управлять углом наклона спинки дивана. Правда здорово?<br />- Но мне нужна была всего лишь скамейка...<br />- Мы специалисты в своем деле, не волнуйтесь. Мы можем предугадать ваши дальнейшие потребности, и заложить механизмы реализации уже прямо сейчас. Как вам идея сделать вместо ножек у дивана гусеницы? Это поможет вам передвигаться на нем по пересеченной местности...<br />- Да я... Просто хотел поставить ее во дворе, чтобы бабушкам было на чем сидеть...<br />... хватает топор... urn:lj:livejournal.com:atom1:about_zero:12503 2008-02-02T13:51:19Z 2008-02-02T13:51:19Z Вот, немножко начал игратся с distributed cvs, т.к. до этого опыта никакого с ними не имел. Далее просто неформальное изложение мыслей, чтобы потом не потерялось...<br />Итак, начинаем играться с mercurial. Почему именно оно, а не darcs или git? Не знаю, честно говоря, просто в памяти отложился.<br />Итак, начинаем тихие игры. Самый лучший кандидат на контроль версий в linux системе имхо это /etc :) С него и начнем. Нам нужно создать 2 репозитория (можно обойтись и одним, но зачем тогда dcvs? :) ).<br />1-й, типа удаленный. Для простоты делаем его в домашнем каталоге. <br />mkdir -p ~/repo/etc<br />cd ~/repo/etc<br />hg init<br />Создали каталог и проинициализировали репозиторий.<br />Далее уже под root идем в /etc<br />cd /etc<br />hg init<br />hg add <br />hg commit -m "initial revision"<br />Проиницализировали типа локальный репозиторий, добавили в него файлы, и закоммитили в локальный репозиторий.<br />При коммите пишем текст сообщения, иначе по-любому поднимется редактор и заставит его написать :)<br />В процессе можно поиграться с <br />hg status - выводит статус файлов в директории относительно хранящихся в локальном репозитории<br />hg log - показывает лог коммитов<br />Теперь отправляем файлы из "локального" в "удаленный" репозиторий (иожно делать и под обычным пользователем)<br />cd /etc<br />hg push ~/repo/etc<br />И получаем их в "удаленном" репозитории<br />cd ~/repo/etc<br />hg update<br /><br />В общем, как я понял, идеология поощряет использование отдельных репозиториев на каждый бранч (путем hg clone), правки там, и потом hg push в родительский, с периодическим выполнением hg poll для обновления содержимого локального репозитория urn:lj:livejournal.com:atom1:about_zero:12281 2008-01-28T19:43:45Z 2008-01-28T19:43:45Z Видимо после небольшого перенапряжения на текущем проекте начали меня посещать несообразные мысли об альтернативном пути в жизни - т.н. downshifting... Ну типа там свалить в Гоа, питаться бананами, и ничего не делать. Как щадящий вариант с минимумом изменений - пользуясь бумом спроса на программистов, свалить куда-нибудь обычным рядовым программистом клепать формочки и запросы, по вечерам выходя в космос и общаясь с астралом. Звучит все это черезвычайно заманчиво, удачно вписываясь в анекдот про негра и сбор бананов. <br />К чему это я все написал? Честно говоря не знаю, просто захотелось структурированно изложить кашу, которая сейчас крутится у меня в голове, авось заодно и смысл жизни найдется, и тогда глупые вопросы перестанут возникать.<br /><br />ЗЫ: А вот неудобно иногда, что в OCaml по умолчанию string &lt;&gt; char list, и нужно писать преобразование ручками. Или это я такой невнимательный? :) urn:lj:livejournal.com:atom1:about_zero:11778 2007-11-22T18:56:09Z 2007-11-25T13:11:28Z Читаю сейчас замечательную книжку Leo Brodie "Thinking Forth" (<a href="http://thinking-forth.sourceforge.net/">ссылка</a>)<br />Несмотря на то, что книга выпущена в 1984 году, актуальности своей она не потеряла. Читаю, и все больше убеждаюсь в корректности изречения "Все новое - это хорошо забытое старое".<br /><br />Создание DSL как основной способ решения задач.<br />Быстрые итерации, прототипирование, постоянное взаимодействие с пользователем - основные постулаты Agile методик. <br /><br />Помимо всего прочего, и сам язык показался мне весьма интересным и приспособленным именно под подобный стиль разработки. urn:lj:livejournal.com:atom1:about_zero:11267 2007-10-25T17:40:21Z 2007-10-25T17:40:21Z "Структура банковских данных слишком сложна, чтобы применять к ней правила реляционного моделирования" - шедевральная цитата, взята <a href="http://dom.bankir.ru/showthread.php?t=77431&amp;page=2">из обсуждения здесь</a>.<br />Это я к тому, что все виденные мной схемы БД для банков, действительно выглядят несколько "лохмато". Широкие таблицы, куча редкоиспользуемых колонок, дублирующихся значений, смешение различных сущностей в одной таблице... Все это в той или иной степени присутствует во всех виденных системах. Похоже, что либо все архитекторы придерживаются этой максимы, либо таков неумолимый эволюционный процесс, что любая схема БД со временем накапливает энтропию и деградирует до 1НФ (или в лучшем случае до 2НФ)? urn:lj:livejournal.com:atom1:about_zero:11094 2007-10-02T16:13:20Z 2007-10-02T16:13:20Z В очередной раз перечитываю "Путь камикадзе" Йордона. До чего же хорошая, успокаивающая и умная книжка... Просто сейчас вживую наблюдаю все то, что написано в книжке, точность попадания и систематизации просто поражающая.... urn:lj:livejournal.com:atom1:about_zero:10911 2007-08-16T16:22:48Z 2007-08-16T16:22:48Z Интересно, какое название лучше подойдет - некропрограммист или археолог-программист? Не хочу ни так, ни так на самом деле... urn:lj:livejournal.com:atom1:about_zero:10642 2007-08-09T17:40:24Z 2007-08-09T17:40:24Z Еще несколько наблюдений из разряда типовых задач для баз данных. Итак, времязависимые данные. Есть 2 основных подхода для хранения периода актуальности у сущности:<br /><br />- EntityPK, ValidFrom. В этом случае периоды постоянства следуют один за другим без разрывов, до следующего ValidFrom с тем же EntityPK. Из явных плюсов - нет проблем с контролем интервалов постоянства (на наличие дырок, на наличие пересечений), нет проблем при загрузке данных в хранилище (нет необходимости корректировать остальные записи). Но есть один явный недостаток - для определения состояния на дату необходим подзапрос<br /><br />- EntityPK, ValidFrom, ValidTo. В этом случае все ровно наоборот - простота выборки и сложность добавления и поддержания согласованности данных.<br /><br />Кроме чистого подхода, можно например оптимизировать первый вариант для наиболее часто встречающегося случая - запрос актуальных данных на текущую дату, путем добавления поля-признака isActualState. Вариантов реализации много, от триггера до materialized view.<br /><br />Но по большому счету это все проблемы физической реализации типа данных - "временной интервал". У Дейта хорошо описано, что это такое и зачем нужно. И вот меня сейчас мучает вопрос - пропустил ли я что-то в возможностях современных СУБД в этой области, или до сих пор нет удобного типа данных для решения подобных задач? <br /><br />Здесь неполный список того, что хотелось бы видеть от этого типа даных.<br />- Задание даты начала, даты конца. Поддержка +/- бесконечности<br />- Получение длительности.<br />- Возможность арифметических действий - сложение, вычитание, пересечение, проверка на равенство.<br />- Проверка вхождения даты в интервал<br />- Возможность построения индекса по полям данного типа<br />- Проверка интервала на уникальность (что нет пересечений с другими значениями данного поля)<br />- Поддержка NULL-значений urn:lj:livejournal.com:atom1:about_zero:10244 2007-07-27T17:51:37Z 2007-07-27T17:51:37Z Планета Шелезяка. Жизни нет, мозгов нет, населена биомассой... urn:lj:livejournal.com:atom1:about_zero:10019 2007-07-26T17:38:09Z 2007-07-26T17:38:09Z Из разряда wtf...<br /><a href="http://dom.bankir.ru/showthread.php?t=75882">Автоматизация</a> во всей красе :)<br />Похоже что разработчиков в Диасе уже не осталось... urn:lj:livejournal.com:atom1:about_zero:9850 2007-07-16T18:52:58Z 2007-07-16T18:52:58Z Интересно наблюдать эволюцию развития банковских систем "у нас" и "у них". Очень четко прослеживается разница в подходах к проектированию и решаемых задачах. Почти все отечественные системы для банков идут от бухгалтерского учета, соответственно, вся доступная информация о движении средств доступна через проводки и остатки на счетах. Т.е. главное - выполнение ПБУ и банковская отчетность, а собственно задачи учета и анализа - вторичны. В забугорных системах (не могу сказать, что я видел их много, но все же...) - изначально все шло похоже именно от задач учета. Этот подход мне нравится больше, для текущих решаемых задач возьму похоже за образец аналогичный подход...<br />Еще до кучи мелкая архитектурная заметка - остатки по валютным счетам. Если мы храним приведенную сумму, то записи будут множиться ежедневно, т.к. курс меняется, соответственно идет переоценка остатка. Другой вариант - таблица курсов. Минус - лишнее соединение, недостаточно таблицы курсов ЦБ, потому что нужен курс на любую дату, в т.ч. и на праздники, что выливается либо в подзапросы, либо в доп. логику при загрузке курсов. А вот при хранении первичных документов проще всего сразу хранить приведенную сумму. Так что надо будет прикинуть и выбрать.