Почему только Делфи?

← →
Другой © (2006-08-24 00:14) [40]

Ketmar © (24.08.06 00:07) [37]

Если у него расширение XML :)

← →
kaif © (2006-08-24 00:18) [41]

2 Ketmar © (24.08.06 00:07) [37]
Спасибо. Блин, я наконец понял, что народ имеет в виду, говоря холивар.
:)

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

Я даже спорить не собираюсь.

← →
Ketmar © (2006-08-24 00:19) [42]

> [40] Другой © (24.08.06 00:14)
XML -- закатать в асфальт. вместе с авторами.

← →
Ketmar © (2006-08-24 00:21) [43]

> [41] kaif © (24.08.06 00:18)
а что тут доказывать? вон, SQLite так и делает -- хранит числа каак строки. и ничего -- работает. %-)

← →
kaif © (2006-08-24 00:21) [44]

Ketmar © (24.08.06 00:19) [42]
XML -- закатать в асфальт. вместе с авторами.

Присоединяюсь.

← →
Дураг (2006-08-24 01:04) [45]

> Чапаев © (24.08.06 00:11) [38]
> а если зипануть его, так объём уменьшится в разы, а то и
> на порядок.
>
> (Для справки: для программиста "на порядок" означает "в
> два раза") ;-)

16 или $0F

← →
Другой © (2006-08-24 01:05) [46]

XML - для экспорта-импорта самое то, для меня.

← →
Ketmar © (2006-08-24 01:11) [47]

> [46] Другой © (24.08.06 01:05)
ну, так -- ещё куда ни шло (хотя есть варианты и получше; всё от данных зависит). но его (XML) ведь пихают сейчас в каждую дырку. а если подходящей дырки нет -- то её обязательно провертят.

← →
atruhin © (2006-08-24 06:46) [48]

> [36] kaif © (24.08.06 00:01)

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

← →
boriskb © (2006-08-24 07:16) [49]

Чапаев © (24.08.06 0:11) [38]
(Для справки: для программиста "на порядок" означает "в два раза") ;-)
Дураг (24.08.06 1:04) [45]
16 или $0F

:)

Люди делятся на 10 типов:
На тех кто понимает двоичное исчесление и на тех кто не понимает.

← →
Думкин © (2006-08-24 07:43) [50]

> atruhin © (24.08.06 06:46) [48]

Он не забывает. Просто он просыпается кажде утро и не вспоминает в каком году он живет. И результат невспоминания весьма далек от времени дбф. А это важно.
Может еще посморим о том чем лучше канализация и выгребные ямы? А потом вы мудро напомните про время в которое это все было востребовано? Если не нравится - то для брезгливых всегда есть еще ямщики и электронная почта.

Каждому овощу свой фрукт. А еще есть такая вещь как стоимость продуктов разработки. Ведь не у всех Дельфи - 60 руб. пачка. А вот это - другая ветка.

← →
Sergey13 © (2006-08-24 09:12) [51]

> [26] DonVik (23.08.06 17:09)
> А вот в Фоксе наоборот, предпочитаю строить отношения
> - мне (лично) так проще проверять правильность связок записей.
Вот посторил ты в фоксе отношения. Пришел я и любым примитивным ДБФЕдитором поковырялся в твоих таблицах. Что ты будешь делать со своими построенными графически отношениями? 8-)

> [48] atruhin © (24.08.06 06:46)
> Вы так хаете формат dbf, но забываете в каком году он был
> создан.
Ничего он не хает, а уж тем более формат. Это отличный формат для операций обмена информацией между разнородными базами/программами. Фактически стандартный формат. Но как СУБД - это вчерашний (даже позавчерашний) день.

← →
Danilka © (2006-08-24 11:21) [52]

[35] kaif © (23.08.06 23:48)
> Есть ли какие-либо задачи, которые невозможно было бы решить,
> не прибегая к хитроумным индексам по выражениям, использующим
> пользовательские функции?

Нет конечно, ничего невозможного нет, но, довольно удобно.
например, в поле "дата документа" мы храним как дату, так и время.
но, по условиям задачи чаще всего требуется документы за день, или за целое количество дней, тогда мы делаем индекс по ф-ии trunc(doc_date), и, соответственно, запрос select ... from ... where trunc(doc_date) = sysdate, будет использовать этот индекс.
Обойтись можно, но с этим удобно.
жаль, в mssql нету такого. там ваще trunc по дате нету :(((

ps. это я уже про орокол, а не дбф-ки. :)

← →
kaif © (2006-08-24 14:01) [53]

2 Danilka © (24.08.06 11:21) [52]
А почему бы не завести два поля - одно типа DATE, а другое типа TIME?
Или в MSSQL нет таких типов полей?

← →
kaif © (2006-08-24 14:05) [54]

atruhin © (24.08.06 06:46) [48]
> [36] kaif © (24.08.06 00:01)

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

Это объясняет хранение концевых пробелов строк.
Но вряд ли объясняет отсуствие бинарных способов хранения чисел.
Вы не находите?

[53] kaif © (24.08.06 14:01)
в MSSQL, также как и в Орокле, нет отдельных типов данных для хранения даты без времени и времени без даты.
То, что можно обойтись без индексов по функции никто не спорит.
Просто я хотел показать удобство такого индекса.

2 Danilka © (24.08.06 15:55) [55]
А я и не отрицаю удобство этих индексов. Просто это единственное преимущество. Я думаю, что если бы на предмет таких индексов по функциям кто-нибудь сумел развить и строгую реляционную теорию, то и сервера бы стали такие индексы поддерживать.
Но SQL дает некоторые преимущества, в частности, автору вопроса встречный вопрос.
Допустим у меня имеется таблица Из двух полей:
NAME, VALUE
В SQL я могу применить запрос с группировкой такого вида:

SELECT NAME, SUM(VALUE)
GROUP BY NAME

И мне не надо его отлаживать вообще.

Или еще интереснее.
имеются 2 таблицы.
T1(GOOD_NAME, CATEGORY_ID, PRICE, QUANTITY)
T2(CATEGORY_ID, CATEGORY_NAME)

И я могу запросить суммарную стоимость всего товара для каждой категории одним махом:

SELECT T2.GATEGORY_NAME, SUM(T1.PRICE*T1.QUANTITY)
FROM T1,T2
WHERE T1.CATEGORY_ID = T2.CATEGORY_ID
GROUP BY T2.GATEGORY_NAME

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

но, по условиям задачи чаще всего требуется документы за день, или за целое количество дней, тогда мы делаем индекс по ф-ии trunc(doc_date), и, соответственно, запрос select ... from ... where trunc(doc_date) = sysdate, будет использовать этот индекс.
Обойтись можно, но с этим удобно.
жаль, в mssql нету такого. там ваще trunc по дате нету :(((

(mmsql2k)
Если я правильно понял, можно создать вычисляемое поле, а на него индекс.

DT - дата с временем.
D - дата отформатированная в dd.mm.yyyy без времени.
(а можно было конвертнуть и в int.)

CREATE TABLE dbo.TableName ( ID int IDENTITY (1, 1) NOT NULL , DT datetime NOT NULL , D AS (convert(varchar,DT,104)) ) ON PRIMARY GO CREATE INDEX IX_D ON dbo.TableName(D) ON [PRIMARY] GO

Или какие-то другие "индексы по функции" имеются в виду.

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

PS Лет 8 работал с DBF (на dBase разных версий, FoxBase, FoxPro разных версий, Clipper разных версий). Использовал двоичную упаковку чисел в 2 и 4 байта, как говорил Ашот. Рад, что теперь съехал с этого "формата".

Хотел я сначала написать и очень много, по после прочтения всей ветки вижу что не стоит.

> Marser © (23.08.06 15:56) [5]
> Как известно, гораздо проще забить шуруп молотком, чем завинтить гвоздь отвёрткой.
Дальше читать не стал, ибо все сказано :))) и по сравнениям ммм vs ххх тоже :)))) за великую хахляцкую мудрость блин :))))

Почему только Делфи? Найти похожие ветки