Здравствуйте, _FRED_, Вы писали:


_FR>А "полноценный" — это очень растяжимое понятие, поэтому неполноценным назвать можно очень многое, что ни разу не скажет о функциональности И оценивать "полноценностью" результат какой-либо работы очень странно.

Ну, я под полноценным понимаю минимальный набор фич для собственно движка субд. Щасс по шею и два метра с гаком в десктопе, в "быстрой" памяти остались самые основы, но у Хендерсона и в "Inside Microsoft SQL Server 2005: The Storage Engine" всё весьма подробно разжёвано.

Здравствуйте, Аноним, Вы писали:

А>Да не... нельзя здесь. Речь не об этом. А что если я СУБД пишу?
Искать ближайшую стенку. Реализация нормального store-движка со всеми примочками — примерно два человеко-года.

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

Здравствуйте, QrystaL, Вы писали:
QL>Использовать СУБД
Да не... нельзя здесь. Речь не об этом. А что если я СУБД пишу?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, cvetkov, Вы писали:

C>>Здравствуйте, <Аноним>, Вы писали:

А>>>SomeManager он их может сортировать, может менять у них поля и т.п. Так вот в файл данный должен писать
А>>>SomeManager или Some посредством свойств?
C>>Или даже ктото третий. Есть разные подходы.
А>Так, вот... насчет третьего я знаю... а вчем между ними разница? Когда как правильно делать?

Правильно как удобнее, а удобнее будет если объект сам будет отвечать за хранение собственных свойств(они же его свойства)

Здравствуйте, Sinix, Вы писали:

А>>Да не... нельзя здесь. Речь не об этом. А что если я СУБД пишу?
S>Искать ближайшую стенку. Реализация нормального store-движка со всеми примочками — примерно два человеко-года.

S>Для начала предлагаю подумать над тем, что вы будете делать, когда длина нового значения two окажется больше предыдущего. Где-нить в начале терабайтного файла

Ну тут-то всё просто — нужно продумать структуру хранилища, разбивать данные на pages/extents, подумать над заголовками — наработак, думаю, найти можно не мало.

Предположим есть класс, несколько полей.

class Some
{
public int one;
public string two;
public int three;
...
}

При сериализации берутся все его поля и записываются в файл. При десериализации обратная вещь. А как быть если при изменении одного поля мне нужно его сразу сериализовать (значение этого поля). Допустим меняется two, мне нужно сразу в файле поменять значение two. А не записывать one, не записывать three. Как в таком случае должен выглядеть дизайн классов?

Здравствуйте, Аноним, Вы писали:

А>Предположим есть класс, несколько полей.
А>

А>class Some
А>{
А>public int one;
А>public string two;
А>public int three;
А>...
А>}
А>

А>При сериализации берутся все его поля и записываются в файл. При десериализации обратная вещь. А как быть если при изменении одного поля мне нужно его сразу сериализовать (значение этого поля). Допустим меняется two, мне нужно сразу в файле поменять значение two. А не записывать one, не записывать three. Как в таком случае должен выглядеть дизайн классов?

Использовать свойства.

А>При сериализации берутся все его поля и записываются в файл. При десериализации обратная вещь. А как быть если при изменении одного поля мне нужно его сразу сериализовать (значение этого поля). Допустим меняется two, мне нужно сразу в файле поменять значение two. А не записывать one, не записывать three. Как в таком случае должен выглядеть дизайн классов?

Использовать СУБД

Здравствуйте, <Аноним>, Вы писали:

А>Да не... нельзя здесь. Речь не об этом. А что если я СУБД пишу?
наити место в файле и обновить. а в чем проблема?

Здравствуйте, cvetkov, Вы писали:

C>Здравствуйте, <Аноним>, Вы писали:

А>>Да не... нельзя здесь. Речь не об этом. А что если я СУБД пишу?
C>наити место в файле и обновить. а в чем проблема?
Ну в чем, в чем...
Предположим объектами класса Some оперирует другой класс
SomeManager он их может сортировать, может менять у них поля и т.п. Так вот в файл данный должен писать
SomeManager или Some посредством свойств?

Здравствуйте, <Аноним>, Вы писали:

А>SomeManager он их может сортировать, может менять у них поля и т.п. Так вот в файл данный должен писать
А>SomeManager или Some посредством свойств?
Или даже ктото третий. Есть разные подходы.

Здравствуйте, cvetkov, Вы писали:

C>Здравствуйте, <Аноним>, Вы писали:

А>>SomeManager он их может сортировать, может менять у них поля и т.п. Так вот в файл данный должен писать
А>>SomeManager или Some посредством свойств?
C>Или даже ктото третий. Есть разные подходы.
Так, вот... насчет третьего я знаю... а вчем между ними разница? Когда как правильно делать?

Здравствуйте, microcod, Вы писали:

M>Правильно как удобнее,
Тут не поспоришь
M>а удобнее будет если объект сам будет отвечать за хранение собственных свойств(они же его свойства)
Ой не всегда...

Здравствуйте, _FRED_, Вы писали:

_FR>Ну тут-то всё просто — нужно продумать структуру хранилища, разбивать данные на pages/extents, подумать над заголовками — наработак, думаю, найти можно не мало.
Наработки и полноценный store-движок — эт две оччень большие разницы

Здравствуйте, Sinix, Вы писали:

_FR>>Ну тут-то всё просто — нужно продумать структуру хранилища, разбивать данные на pages/extents, подумать над заголовками — наработак, думаю, найти можно не мало.
S>Наработки и полноценный store-движок — эт две оччень большие разницы

А "полноценный" — это очень растяжимое понятие, поэтому неполноценным назвать можно очень многое, что ни разу не скажет о функциональности И оценивать "полноценностью" результат какой-либо работы очень странно.

Например, многие и студию считают неполноценным средством разработки без ассиста или решарпера. Или ОпенОфис неполноценным заменителем офиса майкрософтовского. Или офис майкрософтовский неполноценным продуктом вообще (как и все майкрософтовские продукты) [все имена и названия являются вымышленными, любые совпадения случайны]

Здравствуйте, Аноним, Вы писали:

QL>>Использовать СУБД
А>Да не... нельзя здесь. Речь не об этом. А что если я СУБД пишу?

И встраиваемую нельзя? Например вот эту: http://www.mcobject.com/perst
Изобретать такие велосипеды — это действительно непросто.

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