Подскажите уважаемые мастера...

← →
Sairex © (2008-02-26 15:17) [0]

Вообщем ломаю голову как сохранить инфу такого типа:
---------------
Наименование
Код
Описание
Примечание
---------------
БД (BDE и т.п.) не предлагать. Думал использовать ИНИ, но через 4 дня файлик будет весить свыше 64 Кб. Может кто подскажет как лучше это все сделать?

← →
Джо © (2008-02-26 15:19) [1]

> [0] Sairex © (26.02.08 15:17)
> Вообщем ломаю голову как сохранить инфу такого типа:
> ---------------
> Наименование
> Код
> Описание
> Примечание
> ---------------
> БД (BDE и т.п.) не предлагать. Думал использовать ИНИ, но
> через 4 дня файлик будет весить свыше 64 Кб. Может кто подскажет
> как лучше это все сделать?

А в чем проблема? Так и записывай в файл: Наименование, Код, Описание, Примечание.

← →
Palladin © (2008-02-26 15:20) [2]

Тайп
ТИнфаТакогоТипа=Рекорд
Наименование:какогото_типа;
Код:еще_какогото_типа;
Описание:еще_какогото_другого_типа;
Примечание:вообще_непонятного_типа;
Энд;

а... фик его знает как сохранить... я с такими типами не встречался...

← →
tesseract © (2008-02-26 15:22) [3]

> Думал использовать ИНИ, но через 4 дня файлик будет весить
> свыше 64 Кб.

Это что много ? Оптимально просто структурированная табличка. Можешь индексы прикрутить, если не лень.

BlockWrite(File,MyREcord[i],Sizeof(MyRecord));

← →
Sairex © (2008-02-26 15:34) [4]

Спасибо ребят я чет совсем забыл про типизированый файл...

← →
Правильный_Вася (2008-02-26 15:35) [5]

> БД (BDE и т.п.) не предлагать.

забобоны какие-то, что ли?

ps bde - это не бд

← →
Reindeer Moss Eater © (2008-02-26 15:51) [6]

Думал использовать ИНИ, но через 4 дня файлик будет весить свыше 64 Кб. Может кто подскажет как лучше это все сделать?

Любой будет больше 64к

← →
Sairex © (2008-02-26 15:55) [7]

> Reindeer Moss Eater © (26.02.08 15:51) [6]
>
> Любой будет больше 64к

Да мне размер файла до лампочки. Насколько я помню у Ини ограничение на 64 кб

← →
Palladin © (2008-02-26 16:11) [8]

только для win9x

← →
Sairex © (2008-02-26 16:22) [9]

> Palladin © (26.02.08 16:11) [8]
> только для win9x

Интересно а кто сейчас Юзает Win9x ? За последний год встречал только 2к, ХП или 2к3 и Висту

← →
Sergey13 © (2008-02-26 16:25) [10]

> [0] Sairex © (26.02.08 15:17)
> но через 4 дня файлик будет весить свыше 64 Кб

А через 4 месяца?

← →
Sairex © (2008-02-26 16:33) [11]

ну если даже метров 60, я думю эт не страшно ;)

← →
Palladin © (2008-02-26 16:39) [12]

страшно, это страшно, это страшно медленно

← →
asail (2008-02-26 16:43) [13]

XML спасет?

← →
Sairex © (2008-02-26 16:50) [14]

> asail (26.02.08 16:43) [13]
> XML спасет?
>

+1

← →
Sergey13 © (2008-02-26 16:53) [15]

> [11] Sairex © (26.02.08 16:33)
> ну если даже метров 60, я думю эт не страшно

И что предполагается с ними делать?

← →
Правильный_Вася (2008-02-26 17:04) [16]

> И что предполагается с ними делать?

велосипед с квадратными колесами

← →
Marser © (2008-02-26 17:20) [17]

> Правильный_Вася (26.02.08 15:35) [5]
> > БД (BDE и т.п.) не предлагать.забобоны какие-то, что ли?
> ps bde - это не бд

Тогда АДО! ;-))))

← →
Marser © (2008-02-26 17:23) [18]

Вот подумалось - а как давно выпали бы в осадок парадоксы с дбейсами, если бы не Борланд с BDE?

← →
VirEx © (2008-02-26 18:05) [19]

Я тоже вот попробовал сериализацией воспользоваться:

object TInventory User = "user" Password = "pass" Limit = -1 object THost Name = "host1" Caption = "caption1" object TItem Name = "nameee" Caption = "caption1.1" object TValue Name = "Name" Caption = "caption1.1.1" LastUpdate = 39504.488267557870000000 Values.Strings = ( "abc" "cdf") LastValues.Strings = ( "bcd" "efg") end object TValue Name = "Caption" Caption = "dgfdfg" LastUpdate = 39504.488266469910000000 Values.Strings = ( "xyz" "xyz") LastValues.Strings = ( "xyz" "xyz") ................... ................... ................... end end object THost Name = "host2" Caption = "caption2" end end

только вот ~20 хостов, по 7 Item"ов заполненных текстовой информацией тянут на 2Мб и открывается/закрывается всё это жуть как медленно

← →
DiamondShark © (2008-02-26 18:20) [20]

> Вот подумалось - а как давно выпали бы в осадок парадоксы
> с дбейсами, если бы не Борланд с BDE?

Дык они и выпали. Вместе с BDE. Этим мёртворождённым чудищем пользовались разве что записные бдсмщики.

← →
isasa © (2008-02-26 18:23) [21]

В TADODataSet, у него есть метод SaveToXML, не?
Правда, этот XML только этот датасет понимает, но ...

← →
@!!ex © (2008-02-26 18:29) [22]

> [21] isasa © (26.02.08 18:23)

И в чем преимущество XML перед типизированным файлом?

← →
VirEx © (2008-02-26 18:54) [23]

преимущество только в наглядности и открытом виде

← →
@!!ex © (2008-02-26 18:58) [24]

> [23] VirEx © (26.02.08 18:54)

Если файлик на 60 метров, использование XML принесет только проблемы... ИМХО

← →
isasa © (2008-02-26 19:06) [25]

Загрузил/выгрузил двумя вызовами, остальное, как с обычным DataSet-ом.
Никаких велосипедов.

← →
isasa © (2008-02-26 19:09) [26]

:)
Да, если юзать типизованый файл, то не забудь предохраняться(packed record) ...

← →
AndreyV © (2008-02-26 19:47) [27]

> [0] Sairex © (26.02.08 15:17)
> БД (BDE и т.п.) не предлагать.

Так в чём, всё-таки, причина антипатии к БД?

← →
Palladin © (2008-02-26 19:51) [28]

>isasa © (26.02.08 19:09) [26]

ну и в чем заключается это предохранение? позвольте поинтересоваться.

← →
tesseract © (2008-02-26 20:16) [29]

> Дык они и выпали. Вместе с BDE. Этим мёртворождённым чудищем
> пользовались разве что записные бдсмщики.

Эх молодёж. SQL перекушали, теперь не знают, как курсоры с индексами работают....

> :)Да, если юзать типизованый файл, то не забудь предохраняться(packed
> record) ...

Строки определённой длины надо устанавливать, packed тут ну ни в какую не впился.

← →
Palladin © (2008-02-26 20:30) [30]

такое чувство, что некоторые товарищи понятия не имеют что такое packed, но где то слышали что оно чем то помогает при сохранении/чтении записи...

← →
Reindeer Moss Eater © (2008-02-26 23:15) [31]

И в чем преимущество XML перед типизированным файлом?

В XPATH

← →
Strate (2008-02-26 23:16) [32]

Palladin © (26.02.08 20:30) [30]
packed

А что это такое?) Точнее чем отличается обычный рекорд, от пакет рекорда?

И кстати никак понять не могу зачем иногда case внутри рекордов встречается, как работет он там?

← →
korneley © (2008-02-26 23:42) [33]

> Точнее чем отличается обычный рекорд, от пакет рекорда?

Могу ошибаться, но по-моему в ТР была опция компилятора "выравнивать переменные по слову", т.е. байт, фактически занимал 2. Таким образом, добиться байт = байт можно было 2-мя способами: выставлением опций компилятора или объявив рекорд как packed. Второе работало при любых опциях. А case внутре рекордов не "работает", он даёт возможность по разному к одному и тому же типу обратиться: Rect.Left, Rect.Top или Rect.TopLeft.X, TopLeft.Y

← →
Palladin © (2008-02-27 01:34) [34]

> Могу ошибаться, но по-моему в ТР была опция компилятора "выравнивать переменные по слову",

угу, только не опция, а директива {$A} + F1 и она и сейчас есть, выравнивание по умолчанию два двойных слова ({$A8}), но на самом деле выравнивание для рекордов идет по размеру самого большого его поля.

Type // казалось бы выравнивание должно быть по qword, ан нет по dword TMR32=Record a:Integer; b:Byte; c:Integer; d:Byte; End; //оптимизированная по размеру версия записи TOptimizedMR32=Record a:Integer; c:Integer; b:Byte; d:Byte; End; // казалось бы выравнивание должно быть по qword, ан нет по word TMR16=Record a:Word; b:Byte; c:Word; d:Byte; End; //а этоо пример упакованной записи меньшей по размеру, н с более медленным доступом к полям TMPR32=Packed Record a:Integer; b:Byte; c:Integer; d:Byte; End; // казалось бы выравнивание должно быть по int64, ан нет по int TMR32=Record a:Integer; b:Byte; c:Integer; d:Byte; End; ShowMessage(IntToStr(SizeOf(TMR16))); ShowMessage(IntToStr(SizeOf(TMR32))); ShowMessage(IntToStr(SizeOf(TOptimizedMR32))); ShowMessage(IntToStr(SizeOf(TMPR32)));

← →
Palladin © (2008-02-27 01:37) [35]

так, второй TMR32 лишний :) тяжело с мобил девайса писать :)

← →
isasa © (2008-02-27 08:35) [36]

Palladin © (26.02.08 20:30) [30]

такое чувство, что некоторые товарищи понятия не имеют что такое packed, но где то слышали что оно чем то помогает при сохранении/чтении записи...

Не только понятия не имеют, но и в гробу видели это выравнивание при перетаскивании типизованного файла из под одной версии в другую.
Тем более что "выравнивание по умолчанию два двойных слова ({$A8}), но на самом деле выравнивание для рекордов идет по размеру самого большого его поля" ...

← →
Anatoly Podgoretsky © (2008-02-27 08:51) [37]

> Palladin (27.02.2008 01:34:34) [34]

Выравнивание оно сложнее, чем ты думаешь и ты это доказал примерами.
Выравнивание по A8 не значит выравнивания каждого члена по qword, оно гарантирует (должно гарантировать) начальный адрес на границу выравнивания.

← →
Reindeer Moss Eater © (2008-02-27 09:14) [38]

И все же xml. Это наше все.
Преимущества:
- легко редактировать сторонними средствами.
- легко визуализировать (превращая xml в text, rtf, html)
- можно так же легко превратить любой xml в datapacket и получить таким образом датасет.
- над данными в xml можно выполнять sql-подобные запросы с помошью xpath
...

← →
isasa © (2008-02-27 10:59) [39]

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

Кроме этого, я использовал практику, при окончательно не сформированной структуре записи

record
... //work space
space: array[1..totalLen-workLen] of byte;
end;

totalLen - const

← →
Palladin © (2008-02-27 11:09) [40]

> Anatoly Podgoretsky © (27.02.08 08:51) [37]

а где я сказал, что оно такое простое? я наоборот предупредил, что хоть и сказано что выравнивание по qword на самом деле все гораздо сложней, и если "на пальцах", A8 говорит лишь о том, что

int64
integer

при будет выравнено по qword (и будет 16б)

а при $A4 будет выравнено по dword (и будет положенные 12б)

правда я и правда недоговорил, про то как размещаются поля записи (класса, object"а)
компилятор всегда старается оптимизировать размещение, например два последовательных байта и один word будут размещаться в одном dword, но byte,word,byte будут уже размещаться в трех word, суть одна - последовательность разная, и это лишь часть айсберга, и $A играет здесь не последнию роль. и не только "гарантирует (должно гарантировать) начальный адрес на границу выравнивания". вот пример:

Type {$A4} TMR64_4=record b:byte; c:word; e:int64; End; {$A8} TMR64_8=record b:byte; c:word; e:int64; End; ShowMessage(IntToStr(SizeOf(TMR64_4))); ShowMessage(IntToStr(SizeOf(TMR64_8)));

т.е. компилятор расположил e:int64 в одном случае по dword, а в другом по qword

вообще об расположении полей записи можно целую статью написать :)
да и речь не совсем об этом, а о полезности использования packed records при чтении/записи: ну да, с одной стороны оно конечно полезно для переносимости, с другой стороны оно нифика не полезно при доступе по скорости обращения к ним в файле. так что говорить, об каком либо предхранении нужно предметно, предохранении от граблей - да, но тоже самое предохранение от тех же граблей выполняется "насильной" установкой директивы $A на другом компиляторе с другим выравниванием по умолчанию, выигрыш в скорости более чем заметен при интенсивной работе с большими объемами данных. это все касается рекордов состоящих из ordinal types и/или массивов и коротких строк. другие types это совсем другой разговор. там выравнивание куда более пофигистично...

← →
isasa © (2008-02-27 11:16) [41]

Palladin © (27.02.08 11:09) [40]

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

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

← →
Palladin © (2008-02-27 11:40) [42]

> другой стороны оно нифика не полезно при доступе по скорости
> обращения к ним в файле

> т.е ты хочешь сказать, что чтение с носителя осуществляется
> по полям?

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

← →
Palladin © (2008-02-27 11:41) [43]

у packed даже быстрее будет немножко наверное...

← →
Sairex © (2008-02-27 17:58) [44]

Ребят еще вопросик. Zlib почему -то не хочет ужимать TMemoryStream? Могет что продскажите?

← →
Palladin © (2008-02-27 18:11) [45]

ага, TMemoryStream.Seek(0,soFromBegining)

← →
Amoeba © (2008-02-27 18:19) [46]

> DiamondShark © (26.02.08 18:20) [20]
>
>
> > Вот подумалось - а как давно выпали бы в осадок парадоксы
> > с дбейсами, если бы не Борланд с BDE?
>
> Дык они и выпали. Вместе с BDE. Этим мёртворождённым чудищем
> пользовались разве что записные бдсмщики.
>

В свое время, по "молодости" тоже оскоромился.

← →
Marser © (2008-02-27 18:33) [47]

> DiamondShark © (26.02.08 18:20) [20]
> > Вот подумалось - а как давно выпали бы в осадок парадоксы
> > с дбейсами, если бы не Борланд с BDE?Дык они и выпали.
> Вместе с BDE. Этим мёртворождённым чудищем пользовались
> разве что записные бдсмщики.

Я наверное, перечитал "1984", но на попытки переписать историю вырабатывается рефлекс. Если даже сейчас находятся чудики, которые его используют, то о чём можно говорить?

> Эх молодёж. SQL перекушали, теперь не знают, как курсоры
> с индексами работают....

А в BDE всякие Query тоже вполне себе даже работали...
Я с BDE практически не работал, когда-то для галочки поигрался совсем чуток с датасетами, а более-менее плотно входил уже в ADO...

← →
asail (2008-02-27 18:39) [48]

По теме:
Я все-же считаю, что XML наиболее правильное решение. Все-ж стандартизация некая.
А вот если данных очень много - тогда БД однозначно! Они как-бы для того и созданы... Причем выбор конкретной БД и технологии доступа к оной уже на прямую зависит от задачи (ну и есчо от ряда параметров).
Нефиг заморачиваться на рекордах... Завтра, может, захочешь эти данные через веб-сервисы лопатить или в какую нибудь 1С заливать или одновременный доступ к данным по сети нескольким юзьверям давать... Помянешь тогда эти типизированные файлы с рекордами нехорошими словами!

← →
asail (2008-02-27 18:43) [49]

> Marser © (27.02.08 18:33) [47]

> А в BDE всякие Query тоже вполне себе даже работали...

Ага, работали... Токо если с каким-нибудь paradox"ом дело имеешь - то ну их нафиг... TTable рулит. (Ох, чую счас бить будут и за парадокс и за TTable и за BDE тож небось перепадет). :-)

← →
korneley © (2008-02-27 19:48) [50]

> > А в BDE всякие Query тоже вполне себе даже работали...
> Ага, работали...

Работали, работали... Я сам был удивлён, когда проявился заказчик 12-и летней давности, с вопросом: "А нельзя ли функционал малость подправить?" На вопрос: "А Вы что, все еще этим пользуютесь?" - ответ: "А нас устраивает..." Жесть...

← →
Amoeba © (2008-02-27 20:04) [51]

> Могу ошибаться, но по-моему в ТР была опция компилятора
> "выравнивать переменные по слову"

Ошибаешься. Не было в те времена такого.

← →
БарЛог © (2008-02-27 20:06) [52]

Файлик записывай, потом архивируй.

← →
Reindeer Moss Eater © (2008-02-27 20:19) [53]

Ребят еще вопросик. Zlib почему -то не хочет ужимать TMemoryStream? Могет что продскажите?

Она-то как раз и хочет и может и жмет.

← →
Sergey13 © (2008-02-28 08:34) [54]

А че все так БДЕ ругают? Это конечно уже дедушка (или бабушка?), но вполне еще трудоспособный. У меня например некоторые проекты уже второй десяток лет под ним работают и каши не просят. Новые конечно начинать на нем не стОит, но и переписывать старые в угоду моде ни за что не буду.

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

← →
asail (2008-02-28 12:48) [56]

> А для повышения скорости работы сделал жалкое подобие индексов.
>

Тобишь очередной велосипед со стапелей спущен :-). Ну что-ж, удачного плавания...

> asail (28.02.08 12:48) [56]
>
> Тобишь очередной велосипед со стапелей спущен :-). Ну что-
> ж, удачного плавания...

Я бы так не сказал... Думаю ты тоже очень часто изобретаешь велосипед...

>В догонку
Кстати заметил, что очень часто выдают фразу про велосипед, говорят люди которые знаю только как написать программу Hello wold, и пытаются доказать что они более умные чем другие.

По пунктам:
1. таскать меньше.
2. Ненадо ставить какие либо сторонние модули или приложения.
3. Набираешься опыта

← →
asail (2008-02-28 15:27) [62]

> Я бы так не сказал... Думаю ты тоже очень часто изобретаешь
> велосипед...

Бывает... Но всячески стараюсь этого избегать!

> Sairex © (28.02.08 13:47) [58]

Попросил бы!!!! Я тебе, кстати, совет дать пытался! А ты вместо того, чтобы сказать - не годиться потому что так-то и так-то, огрызаешься и оскорбить наровишь! Нехорошо!!!

P.S. Helo word я писал, когда еще никакого Delphi в помине не было (как и винды впрочем)! Но письками меряться я с тобой не собираюсь!

Sairex © (28.02.08 10:38) [55]
Разобрался. Просто запутался в параметрах....
А инфу я решил сохранять в типизированый файл с последующим сжатием оного.
А для повышения скорости работы сделал жалкое подобие индексов.
Правда памяти кушает это все дай боже...

Попробуй Firebird
Попробуй Firebird Local

Потом скажи, что тебя это не устроило, и иди своим путем с миром.

ЗЫ. Firebird не хранит концевые пробелы строк в типах CHAR, VARCHAR

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

Что такое "творческий человек" в твоем понимании?
Должен ли творческий человек, например, непрерывно быть озабоченным тем, творческий он человек или нет?

Творческих человеков здесь нет.

А ежели у кого был негативный опыт с BDE то это его личные траблы

Вот должен ли творческий человек немного заглядывать вперед, к примеру?
Возьмем твою структуру код, наименование, описание, примечание. Если ты боишься мегабайтов, значит, возможно, что там будут тысячи, а может и десятки тысяч записей.
OK. Значит, завтра не исключено, что, например, потребуется разбить записи на группы.
Как будешь группу добавлять?
В виде кода группы или в в иде наименования?
Если не обязательно творческому человеку быть идиотом. то скорее всего в виде кода.
OK. А если нужно новую группу создать, с новым кодом? Где будешь наименования групп с их кодами хранить? Вряд ли в EXE-файле, если только у творческих людей не заведена традиция делать все максимально неудобно для юзверя. Значит создашь еще один файл. Структурированный.
OK.
А где теперь гарантия, что при удалении группы из второго файла в первом коды групп не начнут указываить на несуществующую группу?
У нетвороческих людей это называется соблюдением ссылочной целостности данных.
И придется руками еще один примитивный индекс реализовывать, foreign key называется. И так далее.
Пока все это не превратится в доморощенную БД.
Так не лучше ли сразу начать движок БД писать?
И тут возникает вопрос.
Творческому человеку обязательно писать еще один движок БД или творческому человеку все же интереснее создавать что-то новое, используя уже существующий движок БД?
Так что если подумать немного вперед, то еще неизвестно, творческому человеку что лучше...

> [64] Sairex © (28.02.08 16:26)
> Если только юзать уже готовое то какой нафиг из тебя творческий
> человек....

Я так понимаю ОС ты уже написал и среду программирования то-же. 8-)

осЬ Я еще не написал, а собственный скриптовый движок уже да.

> ЗЫ. Firebird не хранит концевые пробелы строк в типах CHAR,
> VARCHAR

это что же получается? что char и varchar там одно и то же?

2 Sergey13 ©

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

Я лишь хочу заинтересовать его базами данных и SQL.

Допустим, мы берем Firebird Local, Delphi и компоненты IBX.
Довольно быстро делается таблица нужной структуры.
И мы можем легко, при помощи SQL команд INSERT, UPDATE И DELETE создавать в ней записи, модифицировать их или удалять. При этом индексы нам не придется реальзовывать руками, если мы захотим создать индексы. Для этого достаточно исполнить команды типа CREATE INDEX.

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

SELECT COUNT(*) FROM таблица

А если нам вздумается выяснить, сколько записей у нас содержат слово "вася", причем невзирая на регистр букв, то мы можем просто выполнить команду

SELECT COUNT(*) FROM таблица
WHERE UPPER(наименование) LIKE "%ВАСЯ%"

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

Palladin © (28.02.08 17:20) [71]

> ЗЫ. Firebird не хранит концевые пробелы строк в типах CHAR,
> VARCHAR

это что же получается? что char и varchar там одно и то же?

Нет, не одно и то же. Строки типа CHAR и VARCHAR не хранят концевых пробелов, но восстанавливают их в момент выборок. Просто восстанавливают по-разному. CHAR строки дополняются до фиксированной длины пробелами, а VARCHAR не дополняются. Например после записи и чтения строки "vasia " в char(30) и varchar(30) получится в одном случае

"vasia ",

а в другом:

"vasia "

Как-то так в общем. Если наврал, пусть Johnmen поправит. Я редко использую тип CHAR вообще и память у меня дырявая.
:)

> но восстанавливают их в момент выборок.

аа... вот все как хитро... если это так, то, ИМХО, неудачное решение... char он на то и сделан фиксированным, что бы оптимально по скорости производились позиционирование/чтение/запись записи... соответсвенно, при оптимизации структуры БД, люди и принимают решение char или varchar...

> Palladin (28.02.2008 17:20:11) [71]

Не путай хранение и обработку. Хранение внутреннее дело сервера, а вот обработка это уже относится к стандартам, в зависимости от типа на клиента получишь разные значения для char и varchar, при одинаковом хранение.

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

> kaif © (28.02.08 17:21) [72]
>
> 2 Sergey13 ©
>
> На самом деле я вовсе не хочу доказывать человеку, что он
> неправ. Так как мне неизвестны его цели. Может быть он просто
> оттачивает искусство написания программ, то есть просто
> учится, а сама задача ему по барабану.
>
> Я лишь хочу заинтересовать его базами данных и SQL.
>
> Ну как, еще не убедил, что этот путь для творческого человека гораздо
> интереснее, так как вместо того чтобы ковыряться в структурах он
> использует отлаженный механизм, который за него уже наковыряли те, кто в > этом собаку съел, и оставляет за собой свободу заниматься той задачей,
> которую сам пожелает и придумать и решить?
>

Хочу сказать что мне просто надоело использовать БД и SQL (на работе постоянно с ними). Вот поэтому я и решил сам написать то что мне нужно своими руками.
Что касается оскорблений - унизить или оскорбить я нестарался и не собирался. Разве что чутог нагрубил но за это думаю вешать не стоит.

> [72] kaif © (28.02.08 17:21)
> 2 Sergey13 ©

Спасибо. Узнал много нового для себя. 8-)

> [77] Sairex © (29.02.08 10:55)
> Хочу сказать что мне просто надоело использовать БД и SQL
> (на работе постоянно с ними).

И после этого ты написал

> [60] Sairex © (28.02.08 15:20)

?

Подскажите уважаемые мастера... Найти похожие ветки