Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
Rus000
2)БД должна регулярно резервироваться

Уже страшно. Если я правильно понимаю, Вы говорите о "регулярном полном бэкапе с потерей данных, введенных после последнего бэкапа".
23 окт 06, 14:14    [3296024]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Rus000
Поэтому если мы используем в М-языке доступ к данным
а) через объектный и SQL-интерфейсы
б) через специально написанные на M (возможно унифицированные) процедуры UPDATE,DELETE, INSERT
то за целостность и согласованность можно не беспокоиться.
Звучит как "если к M-системе прикрутить декларативный язык, оптимизатор запросов и вообще сделать из нее SQL-систему, то за целостность данных можно не беспокоиться"
Что и требовалось доказать :)
Rus000
1)код должен тестироваться прежде чем работать на БД в миллионы денег
Самое смешное в том, что тестирование принципиально не способно гарантировать отсутствие ошибок :)
Поэтому системы, выдерживающие ACID, при прочих равных надежнее.
23 окт 06, 15:00    [3296477]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
softwarer
Rus000
2)БД должна регулярно резервироваться

Уже страшно. Если я правильно понимаю, Вы говорите о "регулярном полном бэкапе с потерей данных, введенных после последнего бэкапа".
В Cache есть полный бэкап, инкрементальный бэкап, журнал. В журнал пишутся транзакции и операции с журналируемыми глобалами. Соответственно, если глобал журналируется, то даже вне транзакций, объявленных скобками TSTART-TCOMMIT, изменения этого глобала пишутся в журнал, и в случае краха могут быть накачены после подъема из бэкапа. Временные глобалы, служащие для хранения промежуточных данных, обычно не журналируются для повышения быстродействия системы.
23 окт 06, 15:05    [3296533]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
andrey_anonymous
Rus000
Поэтому если мы используем в М-языке доступ к данным
а) через объектный и SQL-интерфейсы
б) через специально написанные на M (возможно унифицированные) процедуры UPDATE,DELETE, INSERT
то за целостность и согласованность можно не беспокоиться.
Звучит как "если к M-системе прикрутить декларативный язык, оптимизатор запросов и вообще сделать из нее SQL-систему, то за целостность данных можно не беспокоиться"
Что и требовалось доказать :)

Это в Вашей интерпретации оно звучит так, а в реальности существуют надстройки над М, обеспечивающие целостность данных но не являющиеся SQL-системами.
23 окт 06, 15:12    [3296609]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 LittleCat

"... если глобал журналируется, то даже вне транзакций, объявленных скобками TSTART-TCOMMIT, изменения этого глобала пишутся в журнал ..."

Ссылочку на документацию (где написано что в транзакционный не "до записи", а именно транзакционный журнал попадают модификации всех глобалов, кроме временных конечно) можно ?

А то вон люди, которые по 12 лет с М-системами работают, и то путаются.
23 окт 06, 15:21    [3296699]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
LittleCat
Это в Вашей интерпретации оно звучит так, а в реальности существуют надстройки над М, обеспечивающие целостность данных но не являющиеся SQL-системами.

Да сколько угодно - хоть XQuery, не в том суть.
Я позволю себе немножко переформулировать:
"Чтобы организовать промышленное производство ПО на базе М-системы, в первую очередь необходимо запретить использовать М-язык и построить поверх него интерфейс, поддерживающий ACID."
А поскольку пользователи этого интерфейса - работники наемные, то, во избежание кадровых проблем, интерфейс должен соответствовать одному из общепризнанных отраслевых стандартов. А таковых немного :)
23 окт 06, 15:22    [3296715]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
andrey_anonymous
Rus000
Поэтому если мы используем в М-языке доступ к данным
а) через объектный и SQL-интерфейсы
б) через специально написанные на M (возможно унифицированные) процедуры UPDATE,DELETE, INSERT
то за целостность и согласованность можно не беспокоиться.
Звучит как "если к M-системе прикрутить декларативный язык, оптимизатор запросов и вообще сделать из нее SQL-систему, то за целостность данных можно не беспокоиться"
Что и требовалось доказать :)


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

Я сказал, то, что чистый M имеет уровень абстракции ниже нежели чистый SQL. Если хотите сравнивать на одинаковых уровнях - тогда нужно смотреть кашовую объектную модель и sql-движок.
23 окт 06, 15:30    [3296801]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
andrey_anonymous
Я позволю себе немножко переформулировать:
"Чтобы организовать промышленное производство ПО на базе М-системы, в первую очередь необходимо запретить использовать М-язык и построить поверх него интерфейс, поддерживающий ACID."
А поскольку пользователи этого интерфейса - работники наемные, то, во избежание кадровых проблем, интерфейс должен соответствовать одному из общепризнанных отраслевых стандартов. А таковых немного :)


в этой трактовке готов согласиться
23 окт 06, 15:33    [3296826]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Andreww

"... если глобал журналируется, то даже вне транзакций, объявленных скобками TSTART-TCOMMIT, изменения этого глобала пишутся в журнал ..."

Ссылочку на документацию (где написано что в транзакционный не "до записи", а именно транзакционный журнал попадают модификации всех глобалов, кроме временных конечно) можно ?


Journaling with Transaction Processing
To use transaction processing, your system manager must enable journaling. With one exception, Caché makes a record in the journal file for:
All transaction commands
All Set and Kill commands that occur within a transaction
This does not apply to globals mapped to the CACHETEMP database — these are not journaled. After journaling is started nothing further need be done. You do not have to say yes to journal all Set and Kill calls nor do you have to use %JOURNAL to specify which globals to journal. All calls to Set and Kill within a transaction are automatically journaled if journaling is on.

Andreww

А то вон люди, которые по 12 лет с М-системами работают, и то путаются.


в чем путаются эти люди?
23 окт 06, 15:41    [3296899]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Andreww
2 LittleCat

"... если глобал журналируется, то даже вне транзакций, объявленных скобками TSTART-TCOMMIT, изменения этого глобала пишутся в журнал ..."

Ссылочку на документацию (где написано что в транзакционный не "до записи", а именно транзакционный журнал попадают модификации всех глобалов, кроме временных конечно) можно ?

А то вон люди, которые по 12 лет с М-системами работают, и то путаются.

Ссылочку
легко.
23 окт 06, 15:41    [3296901]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Rus000 & LittleCat

Ну да :

To use transaction processing, your system manager must enable journaling. With one exception, Caché makes a record in the journal file for:
All transaction commands
All Set and Kill commands that occur within a transaction

А если, этот самый Set и\или Kill, происходет "ВНЕ ТРАНЗАКЦИИ", т.е.
%INTRANS <= 0 (*) ? Тогда что ? Может разработчик суперквалифицированный ЧАЛ (ФХТАГН !!!) или новичёк из тех самых шести вновь нанятых, запустить command который будет не разу не "occur within a transaction " ? Вот о чём я вопрошаю.


(*)
%INTRANS Detects whether a transaction is currently in progress:

- < 0 means in a transaction, but journaling disabled.
- = 0 means not in a transaction.
- > 0 means` in a transaction.
23 окт 06, 16:22    [3297318]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Andreww

Вы ссылочку-то, что я выше привел, посмотрели ? Там вообще ни слова о транзакциях нету, только о журналировании изменениях в глобалах.
23 окт 06, 16:27    [3297384]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
LittleCat
Andreww

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

Боюсь, придеруться, поэтому сразу поправлюсь, слово о транзакциях есть, в том смысле, что они построены на базе журналирования :-) Но это не уменьшает самостоятельной ценности журналирования на уровне глобалов.
23 окт 06, 16:35    [3297463]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 LittleCat

"Там вообще ни слова о транзакциях нету..."

Да ну !!!!!

Вот ссылочка - http://docs.intersystems.com/cache/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_journal#GHA_journal_overview

И вот на ней разделы :

-Automatic Journaling of Transactions
-Rolling Back Incomplete Transactions

Вот первый же раздел :

"Caché transaction processing uses the journal to store transactions. Caché journals any global update that is part of a transaction regardless of the global journal state setting for the database in which the affected global resides.
The application developer uses commands to:

* Indicate the beginning of a transaction.
* Commit the transaction, if the transaction completes normally.
* Roll back the transaction, if an error is encountered during the transaction. "

А вы говорите ни слова ай-яй-яй:(

Тут же вопрос (в третий раз по моему задаю) :

Если не "начать" транзакцию будет ошибка ? Или транзакция начинается неявно (зачем тогда оператор "начала" нужен, для точки сохранения)? Или каждый DML оператор будет в транзакцию завёрнут ?

Просто пугают куски из догументации типа :

%INTRANS Detects whether a transaction is currently in progress:

* <0 means in a transaction, but journaling disabled.
* 0 means not in a transaction.
* >0 means` in a transaction.

Как это "0 - НЕ В ТРАНЗАКЦИИ" ! А где ?! Нафигаж тогда журналы городить если могут быть операторы которые "not in a transaction" ? Они попадают напрямую в файл данных или куда ?
23 окт 06, 16:41    [3297538]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Andreww
2 LittleCat

"Там вообще ни слова о транзакциях нету..."

Да ну !!!!!

....

А вы говорите ни слова ай-яй-яй:(

Я ж говорил, придеруться.... Просто журналирование в М-системах существует очень давно, а вот транзакции в том же Cache появились относительно недавно.
Andreww

Тут же вопрос (в третий раз по моему задаю) :

Если не "начать" транзакцию будет ошибка ? Или транзакция начинается неявно (зачем тогда оператор "начала" нужен, для точки сохранения)? Или каждый DML оператор будет в транзакцию завёрнут ?

Просто пугают куски из догументации типа :

%INTRANS Detects whether a transaction is currently in progress:

* <0 means in a transaction, but journaling disabled.
* 0 means not in a transaction.
* >0 means` in a transaction.

Как это "0 - НЕ В ТРАНЗАКЦИИ" ! А где ?! Нафигаж тогда журналы городить если могут быть операторы которые "not in a transaction" ? Они попадают напрямую в файл данных или куда ?

Отвечаю по порядку:
Если не начать транзакции, ошибки не будет.
Если DML оператор (Set, Kill) изменяет глобал, который журналируется, то это отразится в журнале. Журнал, в частности, служит для восстановления такого глобала после аварий (поднимаем базу из бэкапа и дальше по журналу поднимаем изменения глобала). Транзакции используются там, где требуется атомарное изменение двух или более узлов глобала(ов). Если выдрать кусок из любой документации, не пытаясь вникнуть в суть и не понимая контекста, то немудрено испугаться.
23 окт 06, 16:53    [3297632]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 LittleCat

Все понял. Каждый DML (если не указано принудительно), завёрнут в транзакцию и его изменения патают в журнал. Если нужна группа DML - её заворачиваем в BEGIN TRANS...END TRANS.
23 окт 06, 17:01    [3297685]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Andreww
2 LittleCat

Все понял. Каждый DML (если не указано принудительно), завёрнут в транзакцию и его изменения патают в журнал. Если нужна группа DML - её заворачиваем в BEGIN TRANS...END TRANS.

:-) Ну типа того...
23 окт 06, 17:04    [3297719]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Rus000

Сравнение декларативного запроса на макро-языке неуместно с процедурным кодом M-языка, я уже об этом говорил в одном из ранних топиков на похожую тему. Если уж сравнивать, так длину какого-нть объектного кода, не принимая ввиду его эффективность.

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

Rus000

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

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

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

Rus000

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

А по-моему СКЛ запросы читаются легче чем объектный код.

Rus000

Согласитесь что компактность не догма :)

См. выше об исследованиях ИБМ.

Rus000

Кстати, M-язык очень компактен и вряд ли есть ему конкуренты в этом качестве среди императивных языков

Опять двадцать пять, может не нужно ходить по кругу. Примеры компактности см. тут
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12

Rus000

Ну чисто для примера - левый обход древовидной структуры произвольной вложенности и поиск подстроки "test"

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

Ради справедливости, тот же поиск в СКЛ-е при стандартном представлении дерева в виде
create table tree (
id int default autoincrement not null primary key,
parent int not null references tree.id,
val text);
выглядит так:
select * from tree where val='test';
Синтаксис не проверял, могут быть небольшие ошибки.
24 окт 06, 00:07    [3299187]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
[quot c127Понятность может быть, хотя тоже под вопросом, а вот краткость - нет. Было исследование в середине 80-х, по-моему ИБМ-а, там получилось что программист пишет примерно одинаковое количество операторов в час независимо от языка. Поэтому если задача не может быть решена меньшим числом оператором, т.е. если язык не компактный, то какие-то задачи за заданное время не решаются и требуют больше ресурсов (времени), а это проблема разработчика. Получается на практике компактность это разница между "задача решается" и "задача не решается".
.[/quot]
вот с этим согласен !
но утверждаю : M - компактный язык .
наша система "MX-FIRMA" -
по функциям примерно то же что и "1с-предприятие" ,
и тоже содержит встроенные генераторы отчетов и ввода,
многовалютные операции и все что надо - от путевых листов
до статистики продаж, кадры, производство, и т д,

-- мumps-код на сервере занимает 0.3 MB --

плюс дополнительные настройки в виде мumps-кода
в ячейках EXCEL листов у клиентов - это еще от силы столько же,
притом в системе около 500 отчетных и вводных форм ,
включая все для налоговых служб.
(инсталляшка вместе с MSM (аналог CACHE) занимает 4 mb.)

0.6 mb кода - это не слишком много
сколько в "1с" ? - похоже раз в 10 больше

если бы не MUMPS -
думаю написать и отладить что-то типа "1с"
за приемлемое время (5 лет)
надо группа не 2 человека .
24 окт 06, 10:06    [3299929]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Ну, для начала, вряд ли можно назвать 1C достойным образцом грамотного использования РСУБД.)
24 окт 06, 10:09    [3299948]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

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


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


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


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

c127
А по-моему СКЛ запросы читаются легче чем объектный код.


Думаю это Ваше "имхо". Не могли бы Вы выдернуть из одного из Ваших проектов самый объемный sql-запрос и показать его обществнности? А там уж посмотрим на его понятность

c127

Опять двадцать пять, может не нужно ходить по кругу. Примеры компактности см. тут
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12


опять началась эскалация ... Прочтите внимательно контекст в котором было высказано утверждение о компактности - "среди императивных, т.е. процедурных языков". А Вы про что?

c127

Rus000

Ну чисто для примера - левый обход древовидной структуры произвольной вложенности и поиск подстроки "test"

Чисто для примера была выбрана структура "родная" для иерархических БД. Чисто случайно разумеется. Было бы смешно если бы и там М не был бы компактным.


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

c127

Но оказывается что в жизни таких структур мало, именно по этой причине


ну вот приехали! Что значит мало!? В реальных задачах вообще структур нет, и их придумывают проектировщики и программеры на основании упрощенной модели реально процесса, именно они выбирают оптимальную стратегию хранения данных в ИС.

А разве Вы не знаете, что одноуровневое дерево (ключ-значение) эквивалентно реляционному отношению? И что концептуальная структура данных выраженная в РМД выразима и терминах одноуровненвых деревьев?

Имхо Вы путаете модель и реализацию этой модели

c127

Ради справедливости, тот же поиск в СКЛ-е при стандартном представлении дерева в виде
create table tree (
id int default autoincrement not null primary key,
parent int not null references tree.id,
val text);
выглядит так:
select * from tree where val='test';


не могли бы Вы привести пример скажем минимального трехуровневого дерева в Вашей структуре? мне интересно как это будет выглядеть
24 окт 06, 10:27    [3300064]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
casmith
Member

Откуда:
Сообщений: 84
Rus000
не могли бы Вы привести пример скажем минимального трехуровневого дерева в Вашей структуре? мне интересно как это будет выглядеть

Можно мне попробовать?
create table tree (
id int default autoincrement not null primary key,
level int not null check(level in(1,2,3)),
parent int not null references tree.id,
val text);
Не абсолютно корректный, но один из самых простых для понимания примеров. Древовидные структуры можно организовывать множеством способов.
24 окт 06, 15:45    [3302956]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
casmith
Rus000
не могли бы Вы привести пример скажем минимального трехуровневого дерева в Вашей структуре? мне интересно как это будет выглядеть

Можно мне попробовать?
create table tree (
id int default autoincrement not null primary key,
level int not null check(level in(1,2,3)),
parent int not null references tree.id,
val text);
Не абсолютно корректный, но один из самых простых для понимания примеров. Древовидные структуры можно организовывать множеством способов.


в M (msm - cache - gtm) такая команда создаст трехуровневое
дерево с одним элементом

set ^tree("игрушки","SQL детский","цена")=12.40
24 окт 06, 16:13    [3303254]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 MX -- ALEX

"set ^tree("игрушки","SQL детский","цена")=12.40"

А как же типизация ?

Или то что внутри "" это строки, а 12.40 число ?

Как вообще система типов устроена в М ?
24 окт 06, 16:18    [3303314]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
2 Andreww
А как же типизация ?

По предыдущим обсуждениям вроде выяснили, что типизация - никак.
Всё есть строки.
Если строка выглядит как число, то она может обрабатываться как число. А может и нет. Храниться, впрочем, все равно в строковом виде будет.
Вроде так.
24 окт 06, 16:23    [3303364]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить