Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

24.05.2017

Google
WWW CITForum.ru
С Новым годом!
1999 г

Уважаемые читатели!

После выхода в свет летом 1998 г. книги Криса Дейта и Хью Дарвена Foundation for Object/Relational Databases: The Third Manifesto все свои колонки в журнале Database Programming & Design Дейт основывает на материалах этой книги с добавлением критических замечаний, для книги не очень пригодных. Конечно, я рекомендовал бы всем вам прочитать эту книгу. Но поскольку я понимаю, что это возможно не для всех, то предлагаю хотя бы ознакомиться с основными идеями, читая мои пересказы заметок Дейта. Хочу предупредить, что эти идеи, с моей точки зрения, не бесспорны. Но для понимания сути современных баз данных знакомство с ними очень полезно.

Практически все заметки этой серии посвящены критике объектно-ориентированных баз данных с противопоставлением этих идей идеям Третьего Манифеста. В заметке, пересказ которой предлагается вам сейчас, Крис обсуждает недостатки наличия разных структур данных, хранящихся в базах данных.

Приятного вам чтения, Сергей Кузнецов


Intelligent Enterprise's

Database Programming & Design OnLine
October 1998

According to Date
C.J.Date

Persistence Not Orthogonal to Type

(http://www.dbpd.com/vault/9810/date.html)

Третий манифест не соглашается с объектным миром

В сентябрьском выпуске я объяснял, почему я чувствую, что для концентрации объектного мира на инкапсуляции имеются недостаточные основания. В этом месяце я хочу обратить внимание на другое хорошо известное утверждение мира объектов -- а именно, то утверждение, что постоянство хранения (persistence) ортогонально типу (для краткости я буду ссылаться на это утверждение как на POTT). POTT означает, что (a) любая структура данных, которая может быть создана традиционной прикладной программой -- например, массив, ссылочный список или стек -- может быть сохранена как объект в объектной базе данных и (b) структура таких объектов является видимой для пользователя. Например, объект EX, который является коллекцией служащих данного отдела. EX может быть реализован как список или как массив, и пользователи будут должны знать, как это сделано на самом деле (поскольку соответственно будут различаться операции доступа).

Одной из наиболее ранних статей, если не в самой ранней, выражающей позицию POTT, была статья "Types and Persistence in Database Programming Languages" Малькольма Аткинсона (Malcolm Atkinson) и Питера Бьюнмана (Peter Buneman) (ACM Computing Surveys 19(2), June 1987). Аткинсон был также одним из авторов манифеста "The Object-Oriented Database System Manifesto" [1], предлагавшего набор возможностей, который, по мнению авторов, должна поддерживать СУБД, если она объявляется "объектно-ориентированной". Конечно, среди прочего было включено и свойство POTT.

В последствии манифест "The Third Generation Database System Manifesto" также провозглашал POTT как цель будущих систем баз данных ("Постояноство хранение X для различных X является хорошей идеей") [2]. И авторы The Object Database Standard: ODMG 2.0 также согласны с этим: "[Мы] определяем объектную СУБД как СУБД, интегрирующую возможности базы данных с возможностями объектно-ориентированного языка программирования". Объктная СУБД делает объекты базы данных такими как если бы они были объектами языка программирования… [она] расширяет язык прозрачно постоянно хранимыми данными… и другими возможностями базы данных". [3] (курсив К.Дейта).

Однако занятая мной и Хью Дарвеном позиция в Третьем Манифесте весьма отличается:

"Для постоянного хранения предназначены базы данных (и ничто другое)… [Поскольку] единственным видом переменной, которую мы допускаем в базе данных, является [реляционная переменная] или relvar, единственным видом переменной, которая может обладать свойством постоянного хранения, является relvar".

POTT нарушает независимость данных

Одна из причин, по которой мы отвергаем POTT, является то, что эта идея ведет к утрате независимости данных. Как я уже отмечал, POTT означает, что любая структура данных, которая может быть создана в традиционной прикладной программе, может быть сохранена как объект в объектной базе данных, и структура таких объектов является видимой для пользователя. Конечно, это подход "все годится" по отношению к тому, что может содержаться в базе данных, является основным отличием объектной модели от реляционной, поэтому рассмотрим его более пристально. Замечание: В целях обсуждения я предполагаю, что термин объектная модель является хорошо определенным и хорошо понимаемым, хотя такое предположение -- мягко говоря -- немного льстит объектам.

При принятии этого предположения мы можем охарактеризовать различия между этими двумя подходами следующим образом:

  • Объектная модель говорит, что мы можем поместить в базу данных все, что угодно (любую структуру данных, которую можно создать с использованием механизмов обычного языка программирования).
  • Реляционная модель говорит, по существу, то же самое -- но требует, чтобы все, что бы не было помещено в базу данных, представлялось для пользователя в чисто реляционной форме.

Более точно, реляционная модель совершенно правильно не говорит ничего о том, что может быть физически сохранено. Поэтому она не накладывает никаких ограничений на то, какие структуры данных допустимы на физическом уровне; единственное требование состоит в том, что любые физически хранимые структуры должны отображаться в отношения на логическом уровне и быть скрыты от пользователя. В реляционных системах четко различаются логика и физика (т.е. модель и реализация), а в объектных системах - нет.

Одним из последствий этого положения дел, как уже говорилось -- в противоречии с традиционным здравым смыслом -- является то, что объектные системы могут поддерживать меньшую независимость данных, чем реляционные системы. Например, предположим, что в некоторой объектной базе данных реализация упоминавшегося ранее объекта EX (коллекции служащих данного отдела) изменяется из массива в список со ссылками. Что произойдет с существующим программным кодом, обращающимся к объекту EX? Он сломается.

Возможно, мне следует задать еще один вопрос: Зачем нам нужно менять реализацию EX таким способом? Конечно, в основе ответа лежит эффективность. В идеале изменение не должно затрагивать ничего, кроме эффективности; однако на деле это не так.

На самом деле, мне кажется, что возможность наличия всех этих разных способов представления данных на логическом уровне является примером того, что я называю ложной общностью. Я бы даже сказал, что вся эта идея проистекает из неудачи четкого разделения модели и реализации (может понадобиться множество разных представлений на физическом уровне, но они не нужны на логическом уровне). Помню, как однажды сказал Э.Ф. Кодд (E.F. Codd) (в ответ на вопрос на панельной дискуссии): "Если вы скажете, что имеете в своей системе 50 разных способов представления данных [на логическом уровне, конечно], то я скажу вам, что 49 из них - лишние".

POTT порождает дополнительную сложность

Очевидно, что POTT действительно приводит к дополнительной сложности -- под "сложностью" я прежде всего понимаю сложность для пользователя, хотя порождаются большие сложности и для системы. Например, реляционная модель поддерживает только один "генератор типа коллекции" -- RELATION -- совместно с набором операций -- соединение, проекция и т.д. -- которые применимы ко всем "коллекциям" этого типа (другими словами, ко всем отношениям). В отличие от этого, в соответствии с предложениями ODMG поддерживаются четыре генератора типа коллекции - SET, BAG, LIST и ARRAY, для каждого из которых имеется набор операций, применимых ко всем коллекциям данного типа. И я утверждаю, что операции ODMG одновременно сложнее реляционных и обладают меньшей можностью. Вот, например, операции ODMG для списков:

IS_EMPTY
IS_ORDERED
ALLOWS_DUPLICATES
CONTAINS_ELEMENT
INSERT_ELEMENT
REMOTE_ELEMENT
CREATE_ITERATOR
CREATE_BIDIRECTIONAL_ITERATOR
REMOTE_ELEMENT_AT
RETRIEVE_ELEMENT_AT
REPLACE_ELEMENT_AT
INSERT_ELEMENT_AFTER
INSERT_ELEMENT_BEFORE
INSERT_ELEMENT_FIRST
INSERT_ELEMENT_LAST
REMOVE_FIRST_ELEMENT
REMOTE_LAST_ELEMENT
RETRIEVE_FIRST_ELEMENT
RETRIEVE_LAST_ELEMENT
CONCAT
APPEND

Между прочим, стоит заметить мимоходом, что ODMG не поддерживает генератор типа RELATION. Авторы The Object Database Standard: ODMG 2.0 утверждают, что "модель данных ODMG включает реляционную модель данных за счет наличия типа TABLE", но тип TABLE строго недостаточен во многих отношениях; в частности, отсутствуют многие из критических реляционных операций -- например, соединение. В связи с тем утверждением, что модель ODMG "включает реляционную модель" или "является более мощной", имеется много дополнительных проблем, но ограничения размера этой заметки не позволяют рассмотреть их здесь.

Далее, ODMG поддерживает язык запросов OQL - язык только для выборки (операции обновления отсутствуют), который в свободном стиле срисован с SQL. Более конкретно, OQL:

  • Обеспечивает средства составления запросов в стиле SQL - SELECT-FROM-WHERE для множеств, мультимножеств, списков и массивов
  • Обеспечивает аналоги конструкций SQL GROUP BY, HAVING и ORDER BY
  • Поддерживает объединение, пересечение и вычитание, а также специальные операции для списков и массивов (например, "получить первый элемент")
  • Поддерживает "выражения пути" (path expressions) для прохода по связям между объектами.
В The Object Dtabase Standard: ODMG 2.0 содержится ряд утверждений про OQL. Вот пара из них (в обоих случаях курсив добавлен К. Дейтом):
  • "Там, где это возможно, в качестве основы OQL мы используем реляционный стандарт SQL, хотя OQL поддерживает более мощные возможности."
  • "OQL обладает большей мощностью [чем реляционный язык запросов]."

С моей точки зрения, наоборот, OQL очень хорошо иллюстрирует то, что POTT приводит к дополнительной сложности! То есть я утверждаю, что OQL более сложен, а не более мощен (как кажется, люди из мира компьютеров часто путают эти два понятия). И дополнительная сложность порождается тем фактом, что пользователю демонстрируется так много разных структур данных. Мне кажется, что это положение дел является прямым следствием непризнания преимуществ строго разделения модели и реализации.

Исследуем этот вопрос возрастающей сложности немного более пристально. Прежде всего заметим , что когда мы говорим о списках в базе данных, о массивах в базе данных и т.д., мы на самом деле говорим о переменных списков, переменных массивов и т.д. -- равно как, когда мы говорим об отношениях в базе данных, мы на самом деле имеем в виду переменные отношений (relvar). Конечно, в реляционной модели мы находим только один вид переменных - переменные отношений (т.е. переменные, значениями которых являются отношения); реляционная модель не имеет дела с переменными списков или массивов. Поэтому введение, например, переменных списков представляет собой существенный отход от классической реляционной модели.

Почему же этот отход настолько важен? Ортогональность требует, чтобы мы определили целый новый язык запросов для списков -- т.е. набор операций ("алгебру списков?", аналогичный алгебре операций, уже определенных для отношений (реляционной алгебре). Конечно, в связи с этим языком мы также должны побеспокоиться о замкнутости. И мы должны определить набор операций обновления списков, аналогичный существующему реляционному набору. Мы должны быть в состоянии определять для списков ограничения целостности и безопасности и представления списков. Каталог должен описывать переменные списков наряду с переменными отношений. (А что будет собой представлять сам каталог? Переменные списков? Переменные отношений? Смесь того и другого?) Нам нужна теория проектирования списков, аналогичная существующей реляционной теории проектирования. Нам также потребуются руководства относительно того, когда следует использовать переменные списков, а когда переменные отношений. И так далее, поскольку я уверен, что этот перечень не является исчерпывающим.

Предполагая, что такую "алгебру списков" можно определить, и на все вопросы предыдущего параграфа можно удовлетворительно ответить, теперь мы могли бы иметь два способа выполнения действий там, где ранее было достаточно одного. Другими словами, как уже отмечалось, добавление нового вида переменной определенно увеличивает сложность, но не повышает мощность; нет ничего такого (по крайней мере, полезного), что можно было бы сделать с использованием смеси переменных списков и отношений и что нельзя было бы сделать с использованием только переменных отношений. Таким образом, интерфейс пользователя теперь будет более сложным и будет предоставлять больше возможностей выбора, большей частью без хороших руководств относительно того, как делать этот выбор.

В качестве прямого следствия всего этого приложения баз данных -- включая приложения общего назначения и "frond ends" -- станет труднее писать и поддерживать. Эти приложения станут также более уязвимыми к изменениям в структуре базы данных; будет утрачена некоторая часть независимости данных. Подумайте, что произойдет, например, если представление некоторой части информации изменится из переменной отношения на переменную списка или на что-то еще.

Все эти проблемы прямо конфликтуют с Принципом Информации Кодда. Я уверен, что Кодд не случайно назвал его "фундаментальным принципом реляционной модели". Этот принцип можно сформулировать следующим образом: "Вся информация в базе данных должна быть явно представлена в терминах отношений и никак иначе". В своей книге The Relational Model for Database Management Version 2 (Addison-Wesley, 1997) Кодд приводит ряд аргументов в пользу поддержки этого принципа (аргументов, с которыми я, конечно, согласен). Как мы утверждаем в Третьем Манифесте, отношения являются необходимыми и достаточными для представления любых данных (на логическом уровне). Другими словами, мы должны иметь отношения и нам не требуется ничего, кроме отношений.

Так откуда же возникла идея POTT? Мне кажется, здесь мы имеем (как это часто случается) фундаментальную путаницу в понятиях модели и реализации. Более точно, было замечено, что некоторые SQL-продукты не слишком хорошо выполняют некоторые операции (в особенности соединения); на основе этого было сделано предположение, что эффективность была бы улучшена, если бы мы могли использовать, скажем, списки или массивы вместо отношений. Но в этой идее содержится серьезна путаница; в ней смешиваются логический и физический уровни. Никто не утвержает, что, например, списки не могли бы быть полезны на физическом уровне; вопрос в том, должны ли списки и тому подобное демонстрироваться на логическом уровне. И очень строгой позицией защитников реляционного подхода и, частности, авторов Третьего Манифеста является то, что ответом на этот вопрос является "нет".

Литература

  1. Atkinson, Malkolm et al. "The Object-Oriented Dtabase System Manifesto". Proc. First International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan (1989). Elsevier Science, 1990.
  2. Stonebraker, Michael et al. "Third Generation Database System Manifesto". ACM SIGMOD Record 19, No. 3. September, 1990.
  3. Cattell, R.G.G. and Douglas K. Barry (eds.). The Object Database Standard: ODMG 2.0. Morgan Kaufmann, 1997.

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...