21 дек. 2011 г.

Конкуренты, однако

Slashdot сообщает:

"IBM is deploying technology in China that allows meat suppliers to track a single pig all the way from farm animal to pork chop. Pigs are initially identified with a barcoded ear tag. This identification is then put on bins used to track the various pig parts as they pass through the slaughterhouse, processing plant, distribution center and finally to the clear plastic-wrapped package in a grocer's case. If a consumer buys three pork chops in a package, 'you know that these three pieces of pork chop came from pig number 123,' said Paul Chang, who leads global strategy for emerging technologies at IBM. The goal is to control disease outbreaks, but theoretically this technology could allow a grocer to put a picture on the store package of the pig you are eating."

Год назад мы обсуждали реализацию подобной системы для одного из крупных мясокомбинатов Беларуси. Пока дело застыло на стадии переговоров.

А вот в Канаде подобная система действует в отношении рыбы и крабов. Заходишь на сайт, вводишь код с упаковки и видишь откуда рыбка приплыла.

16 дек. 2011 г.

Why is Firebird better DBMS than Oracle?

Не могу не перепостить из блога Милана Бабускова (Milan Babuskov):

Beside being free (both as beer and also open source), you don’t need 24x7 DBA and there are generally less headaches. Here’s a nice example explained by Norman Dumbar in a mailing-list post. Norman administers over 600 Oracle databases and about 40 Firebird ones:

Oracle uses log files for REDO and has ROLLBACK_SEGMENTS or UNDO Segments (depending on Oracle version) for UNDO. It never uses log files for UNDO - and UNDO is what provides Read Consistency/MVCC in an Oracle database.

Changes are written to the LOG_BUFFER (n memory) and periodically - on commit, every 3 seconds max, or when the buffer is 33% full - flushed to the REDO logs. These REDO logs might be archived to disc when they fill up. That Depends on the database archive log mode though.

These logs are used when a database is restored and rolled forward (using the RECOVER DATABASE command, for example).

In order to roll back changes and to ensure read consistency, UNDO is used. These do live on disc - as tablespace files - but remain in memory in the buffer cache alongside data blocks etc.

When a SELECT is started, the data returned are the data from the data blocks. Each row in a block has an indicator that tells when it was last updated. If a pending update is taking place (currently uncommitted) or if a commit has taken place since this SELECT started then the data read from that data block has changed - and is not consistent with the start time of this SELECT transaction.

When this is detected, Oracle “rolls back” the changes to the start time of the SELECT taking place by looking for the UNDO block(s) associated with the transaction that made the changes. If that results in the correct (consistent) data, that’s what you get.

If it turns out that there were other transactions that also changed the data, they too will be detected and undone.

In this way you only ever see data that was consistent at the start of your own transaction.

As long as the DBA correctly sizes the UNDO tablespace and correctly sets the UNDO_RETENTION parameter to a decent enough value, data changes are able to be rolled back happily all the time.

If the DBA failed miserably in his/her duties, the ORA-01555 Snapshot too old” errors are the result. And are most irritating. Long running SELECTS - batch reports for example - tend to show up this error mostly.

Of course, you would never see such problems with Firebird, because the old record versions are stored in database and not the log files. You don’t have to care if system crashes - after reboot it simply works.

You might think that engineers who build Firebird are smarter than Oracle’s but sometimes I think Oracle is deliberately made so complicated to require DBA and also offer them job security. And also makes sure nobody can complain it’s too easy to use.

#429

Первыми от Беларуси влились в Firebird Foundation под общим номером #429. Рассчитываем взять приз.

7 дек. 2011 г.

etalon.sql

Долгое время формирование эталонной базы данных представляло собой трехступенчатый процесс. Сначала из отдельных файлов в папке SQL создавался скрипт, в результате выполнения которого получалась промежуточная база. Далее, утилита makelbrbtree.exe создавала прямо в этой базе необходимые метаданные интервальных деревьев. Наконец, формировался и выполнялся еще один SQL скрипт (для метаданных и данных, которые должны идти строго после инфраструктуры интервальных деревьев).

Мы изменили утилиту makelbrbtree.exe. Теперь она формирует и возвращает текст с метаданными интервальных деревьев вместо корректировки непосредственно базы данных. Объединив его с имеющимися в папке файлами мы получаем итоговый скрипт etalon.sql для генерации эталонной базы данных от и до за один проход.

PS: а так можно проверить совпадение содержимого двух текстовых файлов в пакетном файле:

...
FC first.txt second.txt /C | FIND "FC: no dif" > nul 
IF ERRORLEVEL 1 goto s_files_are_different
...
:s_files_are_different
...

3 дек. 2011 г.

Розничная торговля под Гедымином

Периодически спрашивают, так что собрал список торговых объектов c кассовой системой на платформе Гедымин по состоянию на декабрь 2011 г.:

Минск

  • "Формат А4", ул Я Коласа (через кассовый сервер Забеллы)
  • "4 сезона", ул Воронянского
  • "Кисея", ул Воронянского
  • "Горячий Хлеб", ул Гурского
  • "Горячий Хлеб", ул Калиновского
  • "Минолита", пр Независимости, 58

Глуск

  • "Домофей"

Гродно

  • "Горизонт" (ОАО "ГОТТЦ "Гарант"), ул.Ожешко, 42
  • "Красотка" (ООО "Молодежный город"), ул.Советская, 29
  • "Явар" (ГорПО), ул.Южная, 9/1
  • "Удобный" (ГорПО), ул. О.Соломовой, 104
  • магазин №6 (ГорПО), ул. Сов.Пограничников, 106

Могилев

  • "4 сезона"
  • "Кисея"

Витебск

  • "Селена"
  • "4 сезона" (два магазина)
  • "Кисея" (4 магазина)
  • "Мир Шин"

Брестская обл, д. Парохонск

  • ОАО "Парохонское"
Если что-то пропустил — пишите в комментариях.