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

22.01.2017

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

Дубликаты, неопределенные значения, первичные и возможные ключи
и другие экзотические прелести языка SQL

Сергей Кузнецов

Наверное, многим знатокам языка SQL содержимое этой заметки покажется тривиальным. Особенно тем, кто читает колонку Криса Дейта в журнале "Database Programming and Design" (www.dbpd.com). Поверьте, что я не конкурирую с уважаемым господином (и моим любимым автором) Дейтом, а лишь хочу высказать свои собственные соображения, возникшие в ходе подготовки практического курса по языку SQL. Я занимаюсь вопросами, связанными с организацией доступа к базам данных, уже более 20 лет, и поэтому мне самому было странно обнаружить в языке SQL некоторые неафишируемые, но глубоко присущие ему свойства, отстраняющие язык от классической реляционной теории.

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

Язык SQL подобно языку Си (покажите мне того, кто его искренне любит) возник вовремя. Людям нравятся компромиссы. Компромиссы любят и создаваемые ими предметы. SQL - это классический пример языка баз данных, с самого начала основанный на компромиссах. Господа, Вы хотите иметь реляционный язык? OK, вот он, реляционно полный (доказано!) язык. Господа, Вы хотите сохранить житейскую правду жизни при ее моделировании в базах данных? OK, вот он - язык SQL, близкий и полезный неортодоксальным пользователям баз данных. За что боролись, то и имеем... Примером бескомпромиссного языка был Quel. Чистый, понятный, основанный исключительно на реляционном исчислении кортежей. Его не приняли.

Да, язык SQL действительно реляционно полон. То есть, на нем можно выразить любое выражение классической реляционной алгебры или любую формулу реляционного исчисления. Но, к сожалению, на языке SQL можно сказать гораздо больше, и к какой языковой группе относятся расширения - остается непонятным...

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

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

Поскольку язык SQL является компромиссом между требованиями теории и практики, в нем отсутствие в таблицах дублирующих строк не является абсолютным требованием. То есть хорошим тоном является отказ от использования таких таблиц, но язык этого не требует. На самом деле, отказ от полного запрета дублирующих строк вызывает очень далеко идущие последствия.

Например, по этой причине пришлось переопределить семантику теоретико-множественных операций над таблицами. В SQL имеются операции UNION ALL (расширенное объединение), INTERSECT ALL (расширенное пересечение) и EXCEPT ALL (расширенное вычитание), выполнение которых не уничтожает строки-дубликаты в результате. Если такая операция выполняется над таблицами T1 и T2, и некоторый кортеж C входит в обе таблицы, причем содержит n дубликатов в таблице T1 и m дубликатов в таблице T2, то в результате операции T1 UNION ALL T2 будет содержаться n+m дубликатов C, в результате операции T1 INTERSECT ALL T2 - min(n, m) дубликатов С, а в результате T1 EXCEPT ALL T2 - max((n-m), 0) дубликатов C. Похоже, что такая трактовка "теоретико-мультимножественных" операций введена исключительно для определенности и не подкрепляется какими-либо здравыми доводами.

Но это, конечно, далеко не все последствия, которые вызвал отказ от запрета дубликатов.

Возможные и первичные ключи
Когда читаешь описание языка SQL (например, стандарт SQL/92), как-то не сразу обращаешь внимание, что при определении схемы таблицы (оператор CREATE TABLE) разделы PRIMARY KEY и UNIQUE являются необязательными. Зато сразу бросается в глаза определение таблицы, в которой не задан первичный ключ. Лично я впервые в своей практике столкнулся с такими таблицами в демонстрационной базе данных pubs, поставляемой вместе с Microsoft SQL Server. В этих таблицах, естественно, нет дубликатов, и немного позже мы обсудим реальные причины того, что в них не существует ни одного возможного ключа. Но сам факт наличия подобных таблиц заставил меня по-новому оценить необязательность разделов PRIMARY KEY и UNIQUE в определении таблицы.

На самом деле, как мы увидим ниже, компания Microsoft могла немного по-другому спроектировать схему базы данных pubs, добившись того, чтобы у каждой таблицы существовал хотя бы один возможный ключ. Более того, можно было бы потребовать использовать только такие базовые таблицы, у которых возможный ключ существует. Но все дело в том, что это противоречило бы принципам ортогональности компонентов языка SQL. В описании языка утверждается, что базовые таблицы, динамически создаваемые таблицы (хранимые таблицы, порождаемые при выполнении оператора выборки) и представляемые таблицы (таблицы, материализуемые только при выполнении адресованного к ним оператора языка SQL) могут использоваться равноправно. Даже если мы потребуем, чтобы в таблицах, входящих в основную схему базы данных, отсутствовали дубликаты, а тем самым существовал хотя бы один возможный ключ, мы никогда не сможем гарантировать отсутствие дубликатов (а следовательно, наличие возможного ключа) в порождаемых (хранимых и представляемых) таблицах. Поскольку все виды таблиц равноправны, неразумно требовать наличия возможного ключа у базовых таблиц. Все это звучит логично, и в некоторой степени оправдывает необязательность разделов PRIMARY KEY и UNIQUE.

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

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


CREATE TABLE discounts

(discounttype varchar(40) NO NULL, stor_id char(4),

lowqty smallint, highqty smallint, discount float NO NULL,

FOREIGN KEY stor_id REFERENCES stores)

Как видно, строка таблицы описывает скидку, назначенную для указанного магазина. Однако в то же время строки таблицы могут описывать и потенциально возможные скидки, даже если они не назначены никакому магазину (поэтому столбцы stor_id, lowqty и highqty могут содержать неопределенные значения). С другой стороны, тип и размер скидки могут быть одни и те же для разных магазинов. Тем самым, пара столбцов (discounttype и discount), которые могли бы служить первичным ключом, на самом деле таковыми не являются (остальные столбцы не могут входить в первичный ключ, потому что потенциально содержать неопределенные значения). Тем самым, мы имеем таблицу, принципиально не содержащую первичного ключа и потому (опять же потенциально) включающую строки-дубликаты (смысла в них нет, но ничто не запрещает их появление).

Как мы уже говорили, компания Microsoft могла бы сделать схему базы данных pubs более соответствующей рецептам реляционной теории. Например, можно было бы вместо таблицы discount сделать две таблицы:


CREATE TABLE discounts

(discount_id int NO NULL, discounttype varchar(40) NO NULL,

discount float NO NULL,

PRIMARY KEY (discount_id))



CREATE TABLE discountsstores

(discount_id int NO NULL, stor_id char(4) NO NULL,

lowqty smallint NO NULL, highqty smallint NO NULL,

PRIMARY KEY (discount_id, stor_id),

FOREIGN KEY (discount_id) REFERENCES discounts,

FOREIGN KEY (stor_id) REFERENCES stores)

В обеих новых таблицах с первичным ключом полный порядок. Но ведь SQL никаким образом не стимулирует такое более правильное проектирование баз данных. И именно потому, что в таблицах могут содержаться дубликаты. Раз все равно могут существовать таблицы без первичного ключа, то зачем навязывать первичные ключи при определении таблицы. Компромиссы...

Первичные, возможные, внешние ключи, функциональные зависимости и операция группирования
Я снова воспользуюсь примером из базы данных pubs. В базе данных имеются таблицы sales и stores, определяемые следующим образом:


CREATE TABLE sales (stor_id char(4) NO NULL,

ord_num varchar(20) NO NULL, ord_date datetime NO NULL,

qty smallint NO NULL, payments varchar(12) NO NULL,

title_id tid NO NULL,

PRIMARY KEY (stor_id, ord_num, title_id),

FOREIGN KEY (stor_id) REFERENCES stores,

FOREIGN KEY (title_id) REFERENCES titles)



CREATE TABLE stores (stor_id char(4) NO NULL,

stor_name varchar(40), stor_address varchar(40),

city varchar(20), state char(2), zip char(5),

PRIMARY KEY (stor_id))

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


SELECT stor_name, stor_address, sum(qty)

FROM stores A, sales B

WHERE state = 'CA' AND A.stor_id = B.stor_id

GROUP BY A.stor_id

Мы-то понимаем, что хотим сказать: результат соединения группируется по значениям столбца stor_id, но мы знаем, что идентификатору магазина в таблице stores однозначно соответствует его название и адрес (более точно, существуют функциональные зависимости stor_id -> stor_name и stor_id -> stor_address, потому что stor_id - первичный ключ таблицы stores). Эти зависимости сохраняются и в соединенной таблице (stores INNER JOIN sales ON (stores.store_id = sales.stor_id)). Тем самым, значения полей stor_name и stor_address являются общими характеристиками группы c одинаковыми значениями stor_id соединенной таблицы. Однако при попытке выполнить запрос мы получим диагностику о недопустимости включения в список выборки имен столбцов, не входящих в список группирования. И формально это совершенно правильно, поскольку язык SQL не обязывает реализацию выводить зависимости для порождаемых таблиц, и система не имеет информации о существующих функциональных зависимостях. Более того, язык SQL не предоставляет средств для выражения таких функциональных зависимостей.

Мне казалось, что ситуация изменится, если мы огрубим ситуацию и объявим столбцы stor_name и stor_address возможными ключами. Для этого в языке SQL используется раздел UNIQUE определения таблицы. В частности, в определении таблицы stores добавились бы строчки


UNIQUE (stor_name),

UNIQUE (stor_address)

Теперь уже система имеет полную информацию об однозначном соответствии значений столбцов stor_id, stor_name и stor_address. Однако запрос по-прежнему не выполняется, и диагностика сохраняется той же самой. И опять-таки это формально правильно, поскольку в спецификациях языка четко сказано, что если в запросе используется раздел GROUP BY, то в списке выборки могут участвовать только имена столбцов, входящих в список группирования, и агрегатные функции, применяемые к другим столбцам таблиц, которые перечислены в разделе FROM. Но пользователям от этого не легче. Похожие таблицы очень вероятно используются в практических базах данных, и запросы, подобные приведенному выше, вполне естественны. Для того, чтобы получить запрос, правильно воспринимаемый системой, его придется переформулировать следующим образом:


SELECT stor_name, stor_address, sum(qty)

FROM stores A, sales B

WHERE state = 'CA' AND A.stor_id = B.stor_id

GROUP BY A.stor_id, A.stor_name, A.stor_address

В общем-то ничего страшного, можно написать и так. Но, во-первых, это неестественно: мы вторично сообщаем системе то, что уже было сказано при создании таблицы stores. Во-вторых, если совершенно очевиден способ выполнения операции группирования по столбцу stores.stor_id (поскольку это первичный ключ, то в любой СУБД для столбца stor_id будет создан уникальный индекс), то не очень понятно, как будет выполняться модифицированный запрос (оптимизатор сможет выбирать стратегии сортировки соединенной таблицы по значениям всех трех полей группирования, а также использования одного из трех индексов; поскольку мы объявили stor_name и stor_address возможными ключами, то для этих столбцов тоже вполне вероятно будут созданы уникальные индексы).

И последнее в этой заметке наблюдение. Если классики реляционной теории говорят, что в любом отношении должен существовать хотя бы один возможный ключ, а первичный ключ выбирается неформализуемым образом из набора возможных ключей, то в языке SQL это не так. В соответствии со стандартом, первичный ключ не может содержать неопределенных значений, а ключи, объявляемые с использованием спецификации UNIQUE, - могут содержать неопределенные значения. Следовательно, вообще говоря в таблице SQL-ориентированной базы данных может существовать возможный ключ и одновременно не существовать первичного ключа. Кстати, именно так обстоит дело в исходным вариантом таблицы discounts (если еще раз внимательно посмотреть на ее определение, то можно убедиться, что возможный ключ в смысле языка SQL в этой таблице существует).

Вывод, который мне хотелось бы сделать, совпадает с призывом одного из прогрессивных деятелей: "Люди, будьте бдительны!" (даже если вы пользуетесь стандартным языком баз данных SQL).

Размещение рекламы — тел. +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
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...