Книга посвящена методам объектно-ориентированного программирования для 32-разрядных операционных систем Windows. Рассмотрен широкий круг вопросов разработки диалоговых и многооконных приложений. Обсуждаются вопросы создания различных типов справочных систем приложения, их русификации и преобразования из одного типа в другой. Большое внимание уделено применению механизма исключений для обработки ошибок, работе с шаблонами, многозадачности и взаимодействию потоков. Отдельная глава посвящена созданию библиотек динамической компоновки (DLL). Приведен обширный справочный материал по функциям и классам Visual C++.

Книга рассчитана на читателей, освоивших Delphi и желающих расширить свои знания и возможности проектирования. Охвачен широкий круг вопросов, начиная с типовых решений традиционных вычислительных задач (обработка массивов, векторы, матрицы, решение систем линейных и нелинейных уравнений), и кончая приемами программирования при взаимодействии с механизмами Windows, с приложениями Microsoft Office (Word. Excel, электронной почтой), с портами. Рассматривается обработка документов различных видов. Детально обсуждаются вопросы построения графиков и диаграмм, создание и использование DLL. Излагается методика работы с удаленными модулями данных.
Рассмотренные приемы можно использовать в любых версиях Delphi, включая Delphi 2006. и при работе с любыми версиями Windows (обсуждается адаптация к версиям). В Delphi 2005 и 2006 материал книги может непосредственно использоваться в приложениях VCL Win32 и VCL .NET. Специфические приемы программирования, характерные для .NET, в книге не рассматриваются.
Книга содержит много модулей процедур и функций с подробными пояснениями, а также законченные приложения, которые можно включать в свои проекты. Даются ответы на множество вопросов, часто задаваемых пользователями Delphi на конференциях и форумах.

Эта книга посвящена описанию новой версии одной из наиболее популярных систем разработки приложений Delphi 7.
В книге последовательно изложены концепции объектно-ориентированного программирования, приведен необходимый справочный материал по языку программирования Object Pascal, описана интегрированная среда проектирования IDE и приемы работы с проектами, подробно рассмотрены вопросы программирования графического интерфейса пользователя, применение библиотеки визуальных компонентов VCL и объектов ActiveX, рассмотрены вопросы реализации межсетевого взаимодействия и создания приложений для Internet.
Особое внимание уделено механизмам доступа к серверам баз данных через ODBC и OLE DB. Книга хорошо иллюстрирована и содержит большой объем справочной информации. Изложение материала сопровождается полезными примерами программ.
Книга предназначена как для разработчиков программного обеспечения, так и для широкого круга пользователей, желающих самостоятельно научиться проектировать приложения в среде Windows.

Рассмотрены вопросы, связанные и прогрп мм про никнем икформл обмена между системой ЮПрсднринтис л внешними приложениями, тинными н Delphi. Приведены общие сведения о конфигурации 1С: Предприятие. Ни конкретных примерах показаны приемы программирования и доступ к информационной структуре системы 1С:Предприятие с использованием механизма OLE Automation, а также прямой доступ к данным с помощью SQL-запросов. Уделено внимание вопросам внешнего администрирования системы 1С:Прсдприятие. Материал сопровождается большим количеством практических примеров.

Для программистов.
Автор: Попов С. А.

Книга рассчитана на читателей, освоивших Delphi и желающих расширить свои знания и возможности проектирования. Охвачен широкий круг вопросов, начиная с типовых решений традиционных вычислительных задач (обработка массивов, векторы, матрицы, решение систем линейных и нелинейных уравнений), и кончая приемами программирования при взаимодействии с механизмами Windows, с приложениями Microsoft Office (Word, Excel, электронной почтой), с портами. Рассматривается обработка документов различных видов. Детально обсуждаются вопросы построения графиков и диаграмм, создание и использование DLL. Излагается методика работы с удаленными модулями данных. Специфические приемы программирования, характерные для .NET, в книге не рассматриваются.

Не так давно компания Microsoft известила весь мир о создании новой технологии .NET. Эта технология выводит программирование на новый уровень развития. Специально для нее компания Microsoft разработала язык Си (Си Шарп), который является новейшим на сегодняшний день языком программирования. Он сочетает в себе преимущества уже существующих языков программирования и дополняет их удобными механизмами работы с технологией .NET.
Эта книга позволит вам в короткие сроки ознакомиться, с основными возможностями С#. Вы сможете изучить синтаксис языка, типы данных, классы, свойства, методы, атрибуты и многое другое. Также в книге подробно рассмотрена методика создания приложений для Windows. Все описанные в книге возможности языка подчеркиваются многочисленными примерами. Прочитав эту книгу, вы сможете с легкостью приступить к созданию собственных приложений на языке Си.
Книга будет интересна как новичкам, так и имеющим опыт программистам.

Книга посвящена методам объектно-ориентированного программирования для 32- разрядных операционных систем Windows. Рассмотрен широкий круг вопросов разработки диалоговых и многооконных приложений. Обсуждаются вопросы создания различных типов справочных систем приложения, их русификации и преобразования из одного типа в другой. Большое внимание уделено применению механизма исключений для обработки ошибок, работе с шаблонами, многозадачности и взаимодействию потоков. Отдельная глава посвящена созданию библиотек динамической компоновки (DLL). Приведен обширный справочный материал по функциям и классам Visual C++.

Рассмотрены вопросы, связанные с программированием информационного обмена между системой 1С:Предприятие и внешними приложениями, разработанными в Delphi. Приведены общие сведения о конфигурации системы 1С:Предприятие. На конкретных примерах показаны приемы программирования и доступ к информационной структуре системы 1С:Предприятие с использованием механизма OLE Automation, а также прямой доступ к данным с помощью SQL-запросов. Уделено внимание вопросам внешнего администрирования системы 1С:Предприятие.

В книге рассматривается методика построения прикладных программ для Windows с помощью Delphi 5 и более ранних версии Delphi. Излагаются требовании, которым должна удовлетворять любая программа для Windows, и способы удовлетворения этим требованиям средствами Delphi. Обсуждаются средства интернационализации прикладных программ. Рассматривается построение приложений с множеством форм, текстовых м графических редакторов, приложений мультимедиа, основы мультипликации, печати твкстов и изображений. Излагаются технологии перетаскивания объектов Drag&Drop и Drag&Doc. Обсуждаются вопросы обеспечения бессбойной работы с помощью механизма исключений. Анализируются проблемы развертывания прикладных программ, их установки и настройки. Приводятся примеры создания прикладных программ. Методика работы рассматривается для разных версий Delphi, включая Delphi 1, которая не потеряла актуальности и в настоящее время.
Книга рассчитана как ия начинающих пользователей, твк и на опытных разработчиков.

Введение в объектно-ориентированное программирование(методическое пособие для преподавателей информационных технологий).
Данное пособие предназначено для преподавателей осуществляющих переход от традиционного процедурного программирования на языке Turbo Pascal, к объектному программированию, в операционной системе Windows, на языке визуального программирования Delphi. Хотя понятие объекта было введено уже в Turbo Pascal версии 5.5, действительно объектное программирование стало возможным и жизненно необходимым при создании программ в операционной системе Windows.
В связи с тем, что данное пособие не является справочником или учебником для системного программиста, а предназначено для освоения учащимися (и помощи для преподавателей) основ визуального, объектного программирования, в пособии очень кратко будет рассказано о механизмах Delphi, а основное внимание будет уделено описанию и практическому применению основных компонентов для построения приложений самого различного назначения.

Не так давно компания Microsoft известила мир о создании новой технологии .NET. Эта технология выводит программирование на новый уровень развития. Специально для нее компания Microsoft разработала язык C# ( Си Шарп ), котиорый является новейшим на сегодняшний день языком программирования. Он сочетает преимущества уже существующих языков программирования и дополняет их удобными механизмами работы с технологией .NET.
Эта книга позволит вам в короткие сроки ознакомиться с основными возможностями C#. Вы сможете изучить синтаксис языка, типы данных, классы, свойства, методы, атрибуты и многое другое.

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

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

Так как средства системы 1С:Предприятие для работы с распределенными информационными базами поставляются отдельно, сначала кратко остановимся на назначении и основных принципах организации работы системы 1С:Предприятие с территориально удаленными подразделениями.



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

Для решения подобных задач предназначена компонента "Управление распределенными ИБ". С помощью указанной компоненты можно организовать двухуровневую структуру информационных баз (ИБ) системы 1С:Предприятие, состоящую из одной центральной и нескольких периферийных информационных баз, работающих с единой конфигурацией. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.

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

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

В некоторых случаях может возникнуть необходимость в том, чтобы объекты того или иного типа никогда не попадали в те или иные узлы распределенной ИБ или никогда не покидали места своего создания. Для обеспечения такой возможности предназначен механизм настройки параметров миграции объектов. С его помощью можно ограничить распространение изменений объектов того или иного вида. Кроме того, в версии 7.7 системы 1С:Предприятие можно создавать периферийные ИБ, которые будут принимать информацию о измененных объектах из центральной ИБ, но не будут передавать изменения, сделанные в них самих.

Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.

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

Для переноса измененных объектов в распределенной ИБ и для первичного создания периферийной ИБ используется файл переноса данных. Он представляет собой упакованный (сжатый) файл, содержащий объекты информационной базы (все при создании периферийной ИБ или измененные при передаче изменений) в специальном формате. Формат данного файла не предназначен для использования его способами отличными от тех, которые предусмотрены механизмами выгрузки/загрузки и передачи изменений. Файл переноса фактически отражает содержимое объектов информационной базы в формате, не зависящем от формата базы данных. Это позволяет использовать в распределенной информационной системе в различных узлах различные форматы хранения данных, поддерживаемые системой 1С:Предприятие (DBF/CDX и MS SQL Server).



Перенос измененных данных производится "пообъектно". То есть единицей переноса данных является так называемый ведущий объект. С точки зрения работы в распределенной информационной базе в 1С:Предприятии существуют следующие типы ведущих объектов:

константа,

элемент справочника,

документ,

календарь,

счет бухгалтерского учета,

типовая операция.

Вместе с документами переносятся все действия, выполняемые ими в процессе проведения: движения регистров, акты расчета, бухгалтерская операция, проводки. В случае, если при проведении документа производятся изменения периодических реквизитов элемента справочника, то производится перенос всего элемента справочника.

Регистрация изменений объектов производится автоматически при любом изменении объекта, независимо от того каким способом это изменение производилось (интерактивно или из встроенного языка). Кроме того в версии 7.7 системы 1С:Предприятие для таких объектов как элементы справочников и документы появилась возможность управления регистрацией изменений. Для этого у соответствующих объектов метаданных введен признак "Автоматическая регистрация изменений". Если этот признак установлен (значение по умолчанию), то автоматическая регистрация производится, а если признак сброшен, то регистрация не производится и изменения объектов в распределенной ИБ не распространяются. Но и в данном случае, при выполнении записи изменений объектов из встроенного языка можно управлять регистрацией изменений с помощью метода встроенного языка РегистрацияИзменений().

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

Сам ведущий объект;

Идентификатор той ИБ, в которую должно быть передано изменение;

Идентификатор ИБ, в которую должно быть передано изменение, служит для отслеживания переноса данных в каждую из ИБ, с которой данная ИБ обменивается данными. Таким образом, при изменении какого-либо объекта в центральной ИБ в таблицу будет помещено по одной записи для каждой из зарегистрированных периферийных информационных баз. Если же изменение объекта происходит в периферийной ИБ, то в таблицу будет занесена только одна запись, соответствующая центральной ИБ, так как каждая из периферийных ИБ непосредственно взаимодействует только с центральной.

Заметим, что удаление объекта является частным случаем изменения. Оно также помечается в таблице регистрации изменений и передается при выгрузке.

Выгрузка и загрузка изменений

Каждая выгрузка изменений осуществляется в адрес конкретной ИБ. В файл переноса, создаваемый при выгрузке попадают все объекты, записи об изменениях которых содержатся в таблице регистрации изменений для данной ИБ.

Заметим, что выгружаются не изменения объектов, а сами измененные объекты. То есть, если в документе изменилось значение одного реквизита, то будет передаваться весь документ и он будет полностью перезаписан на той ИБ, в которую переносится. Как уже отмечалось, вместе с документом будут перенесены и сделанные им движения регистров, операция и проводки. Если изменяется любой реквизит справочника, то передается полностью весь элемент. При этом история периодических реквизитов передается целиком. Последнее означает, что изменения сделанные в истории периодического реквизита элемента на в двух ИБ не будут сливаться вместе.

В процессе выгрузки в таблице регистрации изменений отмечается выгрузка изменений объектов.

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

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

Причем выгрузка измененного объекта будет производиться до тех пор, пока не будет получено подтверждение, о доставке изменения. Это значит, что если выполнять перенос все время в одном направлении и не выполнять обратного переноса то объем файла переноса данных будет все время расти, так как каждый раз будут передаваться все объекты, измененные после последнего полученного подтверждения.

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

Изменения конфигурации

Как уже отмечалось, при работе с распределенной ИБ, конфигурация системы может быть изменена только в центральном узле.

Для регистрации изменений конфигурации и передачи ее на периферийные ИБ используется тот же механизм, что и для объектов данных. При записи измененной конфигурации, в таблицу регистрации изменений объектов по числу известных периферийных ИБ заносятся записи, фиксирующие факт изменения конфигурации.

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

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

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

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

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

Продолжение статьи


[pagebreak]

Загрузка измененной конфигурации может завершиться неудачей, если измененная конфигурация не соответствует существующим данным. Например, было уменьшено число уровней справочника, а новое число уровней оказывается меньшим, чем фактически содержащееся в справочнике или в других подобных случаях. Если такое произошло, то следует привести данные в соответствие с новой конфигурацией или изменить конфигурацию в центральной ИБ и заново произвести выгрузку, чтобы ликвидировать возникшее противоречие.

Коллизии

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

Один и тот же объект изменен более чем в одной ИБ.

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

Объект, измененный в одной ИБ, удален в другой.

В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.

Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ.

Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.

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

В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.

При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.

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

Параметры миграции

С помощью настройки параметров миграции можно ограничивать области распространения изменений объектов. Настройка параметров миграции происходит по видам "ведущих" объектов. То есть для каждого вида "ведущих" объектов можно определить конкретную настройку параметров миграции. В настройке параметров миграции объектов ведущую роль играет выбор того или иного варианта области распространения изменений объектов данного вида. Существуют три варианта настройки области распространения:

Все информационные базы. Данный вариант настройки используется по умолчанию для всех объектов. В этом случае любые изменения объектов данного типа будут распространяться по всем узлам распределенной ИБ. Этот вариант обеспечивает полную синхронизацию объектов данного вида во всей распределенной ИБ. Очевидно, что этот вариант наиболее прост для конфигурирования.

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

Место создания и центр. При таком варианте настройки области распространения объектов существенную роль играет понятие места создания объекта. Местом создания объекта считается ИБ, в которой был создан конкретный объект. Естественно, что различные объекты одного вида могут быть созданы в различных ИБ. Однако место создания объекта может быть определено не для всех видов "ведущих" объектов. Для таких объектов как константы, календари или корректные проводки место создания не определено. Поэтому для этих видов объектов вариант настройки "Место создания и центр" не может быть установлен.

В случае выбора такого варианта области распространения, объекты данного вида помимо места их создания попадают еще и на центральную ИБ. То есть, в случае, если для некоторого вида объектов установлена область распространения "Место создания и центр", то для объектов этого вида, созданных на периферийной ИБ, их изменения будут передаваться между местом их создания и центральной ИБ. Для объектов того же вида, созданных на центральной ИБ, изменения не будут передаваться никуда. С помощью такого варианта области распространения можно добиться такого эффекта, что все объекты того или иного вида будут "собираться" на центральной ИБ, а на любой из периферийных ИБ будут находиться только те объекты, для которых она является местом создания.

В случае выбора области распространения "Место создания и центр", для вида объекта можно задать перечень периферийных узлов распределенной ИБ, которые дополнительно включаются в область распространения всех объектов данного вида. Этот перечень задается как список кодов периферийных ИБ, разделенный запятыми. При задании кодов ИБ допускается использование символов-заменителей '*'. Символ-заменитель должен завершать последовательность символов, образующих код одной или нескольких периферийных ИБ. Таким образом, "A*" представляет собой обозначение всех периферийных ИБ, коды которых начинаются символом 'А'. Последовательность "A*B" является ошибочной, так как символ '*' не завершает последовательность символов, представляющих код периферийной ИБ.

Кроме того, как отмечалось выше, дополнительной возможностью управлять распространением изменений объектов в версии 7.7 системы 1С:Предприятие является особый вид периферийных ИБ, которые получают изменения из центральной ИБ, а сами информацию о сделанных в них изменениях не передают. Для создания периферийной ИБ такого рода, надо при ее инициализации указать признак "Только получатель".

Отдельно стоит рассмотреть случай, когда параметры миграции объектов изменяются в процессе изменения конфигурации уже работающей системы. Изменения параметров миграции для каждого из объектов производится независимо от других. То есть, Конфигуратор не отслеживает ссылки между объектами при настройке параметров миграции. Таким образом, при определенных вариантах настройки параметров миграции у некоторых объектов могут появиться ссылки, указывающие "никуда". Ответственность за сохранение ссылочной целостности в распределенных ИБ возлагается на лицо, занимающееся конфигурированием системы. Общим правилом настройки параметров миграции является определение области миграции для конкретного вида объектов равной более широкой, чем область миграции ссылающихся на него объектов. Например, для справочника область миграции должна быть определена не уже, чем области миграции документов и справочников, в которых есть реквизиты типа "справочник" данного вида. Если, например, измерение регистра имеет тип "справочник" данного вида, то область миграции справочника должна покрывать области миграции всех документов, которые могут записать движения данного регистра.

При изменении параметров миграции того или иного объекта система старается привести имеющиеся данные в соответствие с новыми параметрами. Общим принципом здесь является то, что при изменении параметров миграции объекты никогда ни в каком узле распределенной ИБ не удаляются. Даже в том случае, если в соответствии с вновь установленными параметрами миграции их там быть не должно. Изменения производятся лишь в таблице регистрации изменений. Рассмотрим случаи изменения параметров миграции объектов подробнее.

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

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

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

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

Проблемы конфигурирования и администрирования

При разработке конфигурации для распределенной ИБ проявляется ряд объективно существующих проблем, которые решаются как средствами конфигурации, так и административными решениями.

Очевидной проблемой, которая уже упоминалась выше, является уникальная и последовательная нумерация документов и элементов справочников. Для организации уникальной нумерации используется механизм префиксов. Для его включения в конфигурацию, прежде всего, следует выработать некоторую дисциплину, зависимости префикса от ИБ, в которой создается объект. В простейшем случае это может быть собственно код ИБ. Однако часто префикс может автоматически определяться на каждой ИБ, но не являться ее кодом, так как он может участвовать в печатных формах документов и должен быть понятным для пользователей системы. Более сложной задачей является обеспечение сквозной нумерации объектов без префиксов в случае, когда такая нумерация регламентируется нормативными документами. Особенно сложным является обеспечение строго последовательной нумерации. Очевидно, что полного решения данной проблемы не может быть в принципе, так как объекты создаваемые динамически в независимых системах не могут иметь строгой сквозной нумерации. Отчасти данная проблема решается с помощью введения диапазонов номеров, выделяемых для каждой ИБ. Следует заметить, что номера документов и коды справочников не являются внутренними идентификаторами и их уникальность для системы не обязательна. Это значит, что поддержку уникальность номеров и кодов можно отключить для тех видов, объектов, для которых она не нужна. Кроме того, средствами конфигурации можно организовать перенумерацию объектов, например в центральной ИБ. Однако следует иметь ввиду, что эти изменения будут передаваться как и любые другие изменения, что может вызвать достаточно большой объем передаваемых между узлами данных.

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

Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.

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

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

В любых случаях следует учитывать, что раздельный ввод и использование объектов потребует от пользователей правильного ввода данных. Так, например, при вводе нового товара в двух узлах с разными ценами могут иметь место серьезные ошибки в оформлении документов.

Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".

Прародителем сети интернет была сеть ARPANET. Первоначально её разработка финансировалась Управлением перспективного планирования (Advanced Research Projects Agency, или ARPA). Проект стартовал осенью 1968 года и уже в сентябре 1969 года в опытную эксплуатацию был запущен первый участок сети ARPANET.

Сеть ARPANET долгое время являлась тестовым полигоном для исследования сетей с коммутацией пакетов. Однако кроме исследовательских, ARPANET служила и чисто практическим целям. Ученые нескольких университетов, а также сотрудники некоторых военных и государственных исследовательских институтов регулярно её использовали для обмена файлами и сообщениями электронной почты, а так же для работы на удалённых компьютерах. В 1975 году управление сетью было выведено из под контроля ARPA и поручено управлению связи Министерства обороны США. Для военных данная сеть представляла большой интерес, так как позволяла сохранять её работоспособность даже при уничтожении её части, например, при ядерном ударе.

В 1983 году Министерство обороны разделило ARPANET на две связанные сети. При этом за сетью ARPANET были сохранены её исследовательские функции, а для военных целей была сформирована новая сеть, которую назвали MILNET. Физически сеть ARPANET состояла приблизительно из 50 миникомпьютеров типа С30 и С300, выпущенных фирмой BBN Corporation. Они назывались узлами коммутации пакетов и были разбросаны по территории материковой части США и Западной Европы. Сеть MILNET состояла приблизительно из 160 узлов, причём 34 из них были расположены в Европе, а 18 в Тихом Океане и в Азиатско-Тихоокеанском регионе. Сами узлы коммутации пакетов нельзя было использовать для решения вычислительных задач общего плана.

Понимая, что в ближайшем будущем очень важным моментом в научных исследованиях будет процесс обмена данными, Национальный научный фонд (NFS) в 1987 году основал отделение сетевых и коммуникацинных исследований и инфраструктуры. В его задачи входило обеспеченье современными сетевыми коммуникационными средствами учёных и инженеров США. И хотя отделение фонда NFS финансировало основные исследовательские программы в области сетевых коммуникаций, сферой его основных интересов было расширение Internet.

Сеть NSFNET строилась в несколько этапов и быстро преобретала популярность не только в научно-исследовательских кругах, но и в коммерческой среде. К 1991 году фонд NFS и другие государственные учреждения США поняли, что масштабы Internet вышли далеко за отведённые её на этапе разработки рамки университетской и научной сети. К Internet стало подключаться множество организаций, разбросанных по всему Земному шару. Трафик в магистральном канале NSFNET вырос почти до миллиарда пакетов в день, и его пропускной способности 1.5 Мбит/с на отдельных участках стало уже не хватать. Поэтому правительство США начало проводить политику приватизации и коммерческого использования Internet. Фонд NFS принял решение предать магистральную сеть на попечение закрытой акционерной компании и оплачивать доступ к ней для государственных научных и исследовательских организаций.

Семейство TCP/IP

Познакомившись с историей, давайте подробнее рассмотрим, что собой представляют протоколы TCP/IP. TCP/IP - это семейство сетевых протоколов, ориентированных на совместную работу. В состав семейства входит несколько компонентов:

IP (Internet Protocol - межсетевой протокол) - обеспечивает транспортировку пакетов данных с одного компьютера на другой;

ICMP (Internet Control Message Protocol - протокол управляющих сообщений в сети Internet) - отвечает за различные виды низкоуровневой поддержки протокола IP, включая сообщения об ошибках, вспомогательные маршрутизирующие запросы и подтверждения о получении сообщений;

ARP (Address Resolution Protocol - протокол преобразования адресов) - выполняет трансляцию IP-адресов в аппаратные MAC-адреса;

UDP (User Datagram Protocol - протокол передачи дейтаграмм пользователя) и TCP (Transmission Control Protocol - протокол управления передачей) - обеспечивают доставку данных конкретным приложениям на указанном компьютере. Протокол UDP реализует передачу отдельных сообщений без подтверждения доставки, тогда как TCP гарантирует надёжный полнодуплексный канал связи между процессами на двух разных компьютерах с возможностью управления потоком и контроля ошибок.

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

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

Замечание
Говорить о том, что ARP входит в состав семейства протоколов TCP/IP не совсем корректно. Однако это неотъемлемая часть стека протоколов в сетях Ethernet. Для того чтобы отправить данные по сети, IP-адрес хоста должен быть преобразован в физический адрес машины получателя (уникальный адрес сетевой платы). Протокол ARP как раз и предназначен для такой цели.

Самым фундаментальным протоколом Интернета является протокол IP (от англ. Internet Protocol), обеспечивающий передачу данных между двумя удаленными компьютерами. Протокол IP является достаточно простым, и обеспечивает адресацию в сети. В ранних сетях адреса в сети были уникальные целые цифры, сейчас сеть построена по иерархическому принципу.

Стек протоколов TCP/IP имеет четыре основных уровня, поэтому часто говорят, что TCP/IP — это четырехуровневый стек протоколов. Внизу стека расположен интерфейсный уровень, посредством которого происходит связь с аппаратурой. За ним следует уровень IP, поверх которого построены транспортные протоколы TCP и UDP. На вершине стека находится уровень приложений, таких как ftp, telnet и т. д. Как мы уже говорили, IP — это простой протокол, не требующий установления соединения. При отсылке пакета данных, IP, как и все протоколы без соединения, послав пакет, тут же "забывает" о нем. При приеме пакетов с верхних уровней стека, этот протокол обертывает их в IP-пакет и передает необходимому аппаратному обеспечению для отправки в сеть. Однако именно в такой простоте и заключается основное достоинство протокола IP. Дело в том, что поскольку IP является простым протоколом, он никак не связан со структурой физической среды, по которым передаются данные. Для протокола IP главное, что эта физическая среда в принципе способна к передаче пакетов. Поэтому IP работает как в локальных, так и в глобальных сетях, как в синхронном, так и в асинхронном режиме передачи данных, как в обычных линиях связи, так и беспроводных и т. д. А поскольку протокол IP является фундаментом четырехуровнего сте-ка протоколов, то все семейство протоколов TCP/IP также может функционировать в любой сети с любым режимом передачи пакетов.

На сетевом уровне в семействе протоколов TCP/IP предусмотрено два обширных класса служб, которые используются во всех приложениях.

Служба доставки пакетов, не требующая установки соединения.

Надёжная потоковая транспортная служба.

Различие между службами, требующими установления надёжного соединения и службами, не требующими этого, является одним из самых основных вопросов сетевого программирования. Первое, на что следует обратить внимание, это то, что когда мы говорим об установлении соединения, то имеется в виду не соединение между компьютерами посредством физического носителя, а о способе передачи данных по этому носителю. Основное различие состоит в том, что службы, в которых устанавливается надёжное соединение, сохраняют информацию о состоянии и таким образом отслеживают информацию о передаваемых пакетах. В службах же, не требующих надёжного соединения, пакеты передаются независимо друг от друга.

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

Имя базового блока передачи данных зависит от уровня протокола. На канальном уровне это кадр или фрейм, в протоколе IP – пакет, а в протоколе TCP – сегмент. Когда пакет передаётся вниз по стеку протоколов, готовясь к отправке, каждый протокол добавляет в него свой собственный заголовок. Законченный пакет одного протокола становится полезным содержимым пакета, генерируемого следующим протоколом.

Определение

Пакеты, которые посылаются протоколом, не требующим соединения, называются дейтаграммами.

Каждая дейтаграмма является уникальной в том смысле, что никак не зависит от других. Как правило, при работе с протоколами без установления соединения, диалог между клиентом и сервером предельно прост: клиент посылает одиночный запрос, а сервер на него отвечает. При этом каждый новый запрос — это новая транзакция, т. е. инициируемые клиентом запросы никак не связаны друг с другом с точки зрения протокола. Протоколы без установления соединения ненадежны в том смысле, что нет никаких гарантий, что отправленный пакет будет доставлен по месту назначения.

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

Работа протокола с установлением соединения включает в себя три основные фазы:

установление соединения;

обмен данными;

разрыв соединения.

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

В этом смысле работу с протоколом, требующим установления логического соединения можно сравнить с телефонным разговором. Когда мы звоним по телефону, мы сначала набираем номер (установление соединения), затем разговариваем (обмен данными) и по окончании разговора вешаем трубки (разрыв соединения).

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

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

Протоколы транспортного уровня

Протоколами транспортного уровня в четырехуровневом стеке протоколов являются протоколы TCP и UDP.

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

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

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

В-третьих, базовый протокол IP дополняется также механизмами подтверждения получения данных и повторной отправки, на тот случай, если данные не были доставлены.

Если с первыми двумя параметрами все более-менее понятно, то механизм подтверждения/повторной отправки достаточно сложен и его мы рассмотрим подробнее в другой раз.

22 наиболее часто встречаемых ошибок при самостоятельной оптимизации сайта под поисковые системы:

1. Регистрируемая в поисковой системе страница должна содержать ссылки на другие страницы сайта. В противном случае она будет единственным, что проиндексирует поисковая машина.

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

3. При использовании механизма переадресации, регистрировать в поисковых системах необходимо реальный адрес Вашего сайта. Машина все равно будет выдавать ссылки именно на него, а не на redirect.

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

5. Если поисковая машина не понимает переадресацию, то ресурс останется не проиндексированным.

6. Не стоит плодить копии страницы под разными именами, релевантности сайту это не добавит, а на санкции от поисковой машины нарваться можно.

7. Неправильное написание букв национальных алфавитов - вместо русской "С" (эс) английская "С" (це). Данное правило стоит всегда соблюдать.

8. Грамматические ошибки и примкнувшие к ним опечатки. Используйте редакторы с проверкой правописания.

9. Не используйте слова через п р о б е л. Слова, написанные таким образом - поисковая машина воспримет как группу несвязанных символов.
Если требуется установить большое расстояние между буквами - используйте таблицы стилей CSS (напр.: letter-spacing: 7px; ).

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

11. Большое количество индексируемых страниц, не содержащих ключевой информации, снижает релевантность сайта и увеличивает время его индексации.

12. Не стоит создавать несколько страниц настроенных на одинаковый набор ключевых слов. Используйте синонимы или слова близкие по смыслу. Люди при поиске могут набирать фразы по-разному.

13. Использование для выделения тега FONT. Этот тег не увеличивает релевантность выделяемых слов. Используйте, когда это возможно, теги
-
или .

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

15. Использование в META-теге KEYWORDS слов не только не встречающихся в тексте, но и не имеющих к нему никакого отношения. Такие страницы могут считаться спамом.

16. Использование тегов DESCRIPTION и/или TITLE как еще одного тега KEYWORDS (бессмысленный набор ключевых слов)

17. Каждая страница должна иметь индивидуальный тег TITLE, а в идеале и KEYWORDS + DESCRIPTION.

18. Создание множества никому не нужных, невразумительных сателитов. (Хороший, интересный сателит с уникальным и интересным контентом - это совсем другое дело).

19. Частой ошибкой при конструировании сайта является идти "на поводу" оптимизации в ущерб контенту и дизайну.

20. Использование "чужого" контента. Более эффективным является написание собственного уникального контента.

21. Оптимизация страницы более чем под 10 поисковых запросов. На практике лучше каждую страницу оптимизировать под конкретные ключевые слова, причём количество слов не должно превышать 10!

22. Частой ошибкой является необдуманная покупка внешних ссылок с различных веб-сайтов. К данному вопросу стоит относиться очень серьёзно и покупать ссылки только у профессиональных компаний.