Поводом для этой статьи стал комментарий цитирую:
Трактор 05.12.2009 00:32:59
-
Ненадо приписывать web сервисам несуществующие минусы.
>> 1. Не кроссплатформенно
B под линуксом и под виндовсом работают прекрасно. На FreeBSD ты сам говоришь тоже работают.
>> 1С ключезависимо (дорого).
web сервисы не проверяют наличие ключа. //infostart.ru/forum/messages/fo...sage330063
При прямом доступе в базу 1С писать нельзя однозначно. Иначе рискуешь огрести кучу неприятностей.
- оперативная отметка времени (ее значение должно быть уникальным, а в рассматриваемом случае может оказаться не уникальным);
- полнотекстовый поиск будет работать неверно;
- неуникальность номеров и кодов практически гарантирована;
- блокировки объектов (используются в методе Заблокировать прикладных объектов 1С:Предприятия и при их редактировании в диалогах);
Кроме того при прямом доступе недоступен весь функционал 1С. Например в поле Представление адреса в регистре контактной информации это самое представление нужно писать в том виде в каком его возвращает функция глобального модуля, иначе адрес будет трактоваться как иностранный.
Придётся дублировать часть функционала 1С на сайте. А это гемор. -
Он доступен здесь: //infostart.ru/public/62143/?PAGEN_1=1
Попробую опровергнуть по пунктам, но сначала я хочу предупредить: НИКОГДА НЕ ДЕЛАЙТЕ ТО В ЧЁМ НЕ УВЕРЕНЫ!!!
-
При прямом доступе нельзя писать однозначно.
-
Оперативная отметка не будет уникальной.
-
Полнотекстовый поиск будет работать не верно.
-
Не уникальность кодов и номеров.
-
Блокировки объектов при записи в базу.
-
Недоступен функционал.
Первый пункт о невозможности записи. В большинство баз данных писать можно. Для этого существует операторы INSERT и UPDATE. Неприятности мы можем получить и при не правильном конфигурировании 1С.
Второй пункт это вообще интересно. Как формируется ссылка 1С. Это GUID записанный в базу в двоичном виде. Простите за отклонение от темы, но почему его нельзя было писать в нормальном виде, а не bytea(16), я не знаю. Что же такое GUID? GUID (Globally Unique Identifier) — статистически уникальный 128-битный идентификатор. Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов. Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (3,4028×10^38), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, достаточно мала. Хотя три прецедента уже были.
Структура идентификатора:
GUID STRUCT
Data1 dd
Data2 dw
Data3 dw
Data4 dw
Data5 db 6
GUID ENDS
Например, '22345200-abe8-4f60-90c8-0d43c5f6c0f6' соответствует шестнадцатеричному 128-битному числу 0x00523422E8AB604F90C80D43C5F6C0F6
Таким образом правильно сгенерированный GUID будет уникален с достаточно большой долей вероятности.
Как же его пишет 1С? Я в интернете нашел только одну страницу. http://www.itland.ru/forum/lofiversion/index.php/t8595.html. То есть генерируя ссылку 1С мы должны сначала GUID вида 22345200-abe8-4f60-90c8-0d43c5f6c0f6 преобразовывать к виду 90c80d43c5f6c0f64f60abe822345200 и только потом в binary(16). И здесь я должен извиниться за отсутствие кода. Вариантов реализации очень много, а алгоритм не мой, и разрешения на его использования в данной статье у меня нет.
Перейдем к третьему пункту. Полнотекстовый поиск будет работать верно, если мы строки будем вставлять в базу данных в правильной кодировке.
Четвертое. Как же нам добиться уникальности номера? И надо ли? Во первых не все документы и справочники должны иметь уникальные номера и коды. А во вторых не вижу причин что бы не проверить перед записью в базу данных какие номера уникальны, а какие нет.
Например:
...
CREATE TABLE #temp(code as varchar(9))
...
INSERT INTO #temp values(...)
...
SET @C = SELECT COUNT(*)
FROM _ReferenceXXX
INNER JOIN #temp
ON #temp.code = ReferenceXXX.code
IF @C <> 0 THEN ...
ELSE ...
Пятое. Блокировки. Тут выбор настолько велик, что надо читать документацию и выбирать. Как вариант почитать http://www.cybersecurity.ru/manuals/data/mysql/1924.html.
И только шестой пункт я опровергать не буду. Это не оспоримо. Функционал доступный вне 1С гораздо богаче. Но если нужен функционал 1С, возьмите 1С. Зачем пытаться скальпелем валить деревья? 1С подходит в 90% случаев. Более того скорость разработки с ее помощью ОЧЕНЬ высока. Поэтому прибегать к чему-то нестандартному надо только в КРАЙНИХ случаях. С каждой версией 1С таких случаев все меньше.
Однако 2 часа ночи и пора спать. Спасибо Трактору — 90% статьи его.
P.S.
Добравшись до работы, я таки решил проверить как это работает. Написав Функцию для постгреса:
CREATE OR REPLACE function guid_to_bytea(text)
RETURNS text AS $$
my ($s1,$s2,$s3,$s4,$s5) = split('-',$_[0],5);
my @guid = split('',"\U$s4$s5$s3$s2$s1\E");
my $result = "";
for($i = 0 ; $i < $#guid ; $i++) {
$result .= "\\".sprintf("%03o",hex("0x$guid[$i]$guid[$i+1]"));
$i++;
}
return $result;
$$ LANGUAGE plperl;
Я вставил запись в справочник:
INSERT INTO _reference7(
_idrref, _marked, _ismetadata, _code, _description)
VALUES (guid_to_bytea('22345200-abe8-4f60-90c8-0d43c5f6c0f6')::bytea, false, false, '000000002', 'query');
Потом создал новый элемент в 1С. Был приятно удивлен. 1С действительно не контролирует вставку данных в свою базу. Так что если будете вставлять напрямую данные, то за нумерацию и уникальность придется нести ответственность вам. Осталось проверить блокировки.
