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

← →
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]

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

← →
Sairex © (2008-02-28 10:38) [55]

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

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

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

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

← →
Sairex © (2008-02-28 13:44) [57]

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

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

← →
Sairex © (2008-02-28 13:47) [58]

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

← →
Sergey13 © (2008-02-28 14:33) [59]

> [57] Sairex © (28.02.08 13:44)

Тогда может объяснишь, чем твое решение лучше простенькой прикрученной СУБД-шки?

← →
Sairex © (2008-02-28 15:20) [60]

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

← →
Sergey13 © (2008-02-28 15:22) [61]

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

Ха-Ха. 3 раза.

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

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

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

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

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

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

← →
kaif © (2008-02-28 15:33) [63]

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

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

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

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

← →
Sairex © (2008-02-28 16:26) [64]

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

← →
kaif © (2008-02-28 16:42) [65]

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

← →
Игорь Шевченко © (2008-02-28 16:52) [66]

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

А ежели у кого был негативный опыт с 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)

?

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