Как я понял ваша «практика» больше относится к FOREX чем к ФР, но сдается мне такого уровня схемы работаю на любых биржах.
Так вот не могли бы вы пояснить такой переход:
«Если среди хомячков вдруг попадается токсичный поток, то он быстро и легко выявляется, после чего настоятельно рекомендуется перейти в STP-тип, либо закрыть счет.»
«перейти в STP» — это как? ведь STP это модель работы брокера…
На самом деле человек очень гордится проделанной работой и его распирает поделиться! Это очень классное чувство — удовлетворение от пройденного пути и гордость за то что получилось! Удачи с выпуском! ;)
Судя по формулировке: «Доверие участников к системе и друг к другу жизненно важно для работы LETS.», — вроде как и не надо. Но сдается мне что при увеличении числа членов «карму» вводить придется. А вообще можно прям ща садиться и писать очередную социалку — на злобу дня. :)
Мде… Судя по скринам там не атомна война была, а какое-то нашествие кроликов-гениев -> Жизнь бьет ключом. Куча навороченной техники. Стройка… инженеры… Где фоллаут то? Где постапокалипсис? Где мэд макс? Шняга. Пойду второй поставлю :)
«Многие физики склоняются к так называемой «никакой» интерпретации квантовой механики, ёмко выраженной в афоризме Поля Дирака: «Заткнись и считай!»»
( Копенгагенская_интерпретация )
Куб на тетрадном листе все могут нарисовать и представить. А кто видит что-то кроме нагромождения линий в проекции четырехмерного куба на плоскость (Гиперкуб)?
Сдается мне что подобные интерпретации довольно бессмысленны. Есть куда более сложные эффекты (Запутанные_состояния), которые еще сложнее обьяснить оперируя объектами макромира.
Так что прав был Дирак :) Надо считать, описывать свойства и учится их использовать. А различные интерпретации лишь попытка упростить, «спроектировать» обьект и из микромира на представления макромира. Мне кажется это занятие довольно бессмысленным.
Ух! В очередной раз удивляюсь тому как Хабр вытягивает из глубин сознания и памяти такие бесценные забытые-потерянные вещи. А ведь с десяток лет назад так убивался! Так и не прошел... Мал еще был :) Пошел качать! Спасибо!
Да и не так важны детали. Я просто привел пример того как имплементация СУБД может кардинально влиять на схему таблиц и архитектуру приложения в целом.
Не все так просто. Вот цитата из документации Postgres'а 8.3
"UPDATEs and DELETEs leave dead tuples behind, as do failed INSERTs. Previously only VACUUM could reclaim space taken by dead tuples. With HOT dead tuple space can be automatically reclaimed at the time of INSERT or UPDATE if no changes are made to indexed columns. This allows for more consistent performance. Also, HOT avoids adding duplicate index entries. "
И ссылка на разъяснения по-русски: http://citforum.univ.kiev.ua/database/po…
Экономия места лишь на уровне индекса, если не меняется поле по которому построен индекс. Плюс не надо ждать вакууминга для повторного использования места, занимаемого версией строки в которой отпала необходимость. Да к тому же все это верно пока версии строки внутри одной страницы памяти. Так что экономия лишь процентная. Если строки большие (много полей), все это хуже работает. Проблема реально остается.
Из своего опыта работы с разными СУБД могу сказать, что всегда нужно учитывать особенностии конкретной СУБД. Решение SQL задач из общих соображений (без учета особенностей СУБД) к практической реализации имеет мало отношения. Более того в постановке задачи ничего не сказано о профиле данных (частоте изменений свойств обьектов, частоте появления новых обьектов, частоте появления новых типов обьектов и т.д.) Если решать SQL зачади в самом общем виде, то естесвенно надо полагаться на теорию реляционных баз данных, а не выдумывать велосипед. Но в большинстве случаев это не выгодно с точки зрения производительлности.
Примеры:
Postgres:
Особенность: на каждый update поля в строке в действительностии добавляется новая строка, старая остается не видимой для сессии.
Это особенность реализации версионности. Поэтому для Postgres'а оптимально разделять таблицы на более мелкие (вертикальное партицирование). Где в одной будут содержаться редко изменяющиеся поля и таких полей может быть много, в другой часто изменяющиеся и таких полей в одной аблице должно быть как можно меньше. Причем таким образом можно делить даже одну сущность (например "корабль"), что уже не верно с точки зрения реляционной теории.
Oracle:
Особенность: Наличие возможности более гибко влиять на построение плана запроса(oracle hints). Что дает возможность лучше подстраиваться под профиль данных и оптимизировать сложные запросы. Можно выбирать решения больше удовлетворяющие реляционным бд, что дает большую гибкость при выборке данных.
Особенность: наличие очень хорошей имплементации bitmap индексов, сущесвенно ускоряющих выборку по однородным данным и уменьшающим обьем хранимых индексов. Это приводит к необходимости создания буферов. Например в буфферные таблицы с разных клиентов складывается информация об изменении координат обьектов, раз в минуту все данные забираются из буферов и append'ом (оракловый метод вставки большого кол-ва строк) вставляются в основное хранилище, что дает оптимальное построение bitmap индексов.
Таких примеров масса. При выборе архитектуры бд надо изходить из возможностей СУБД и профиля данных, но ни в коем случае не из удобства разработки и написания запросов.
Сдается мне что проблема общая для многих существующих ресурсов, и каждый решает ее по-своему. Пример решения собственно сам хабр. Плоское общество врядли жизнеспособно.
Так вот не могли бы вы пояснить такой переход:
«Если среди хомячков вдруг попадается токсичный поток, то он быстро и легко выявляется, после чего настоятельно рекомендуется перейти в STP-тип, либо закрыть счет.»
«перейти в STP» — это как? ведь STP это модель работы брокера…
( Копенгагенская_интерпретация )
Куб на тетрадном листе все могут нарисовать и представить. А кто видит что-то кроме нагромождения линий в проекции четырехмерного куба на плоскость (Гиперкуб)?
Сдается мне что подобные интерпретации довольно бессмысленны. Есть куда более сложные эффекты (Запутанные_состояния), которые еще сложнее обьяснить оперируя объектами макромира.
Так что прав был Дирак :) Надо считать, описывать свойства и учится их использовать. А различные интерпретации лишь попытка упростить, «спроектировать» обьект и из микромира на представления макромира. Мне кажется это занятие довольно бессмысленным.
"UPDATEs and DELETEs leave dead tuples behind, as do failed INSERTs. Previously only VACUUM could reclaim space taken by dead tuples. With HOT dead tuple space can be automatically reclaimed at the time of INSERT or UPDATE if no changes are made to indexed columns. This allows for more consistent performance. Also, HOT avoids adding duplicate index entries. "
И ссылка на разъяснения по-русски: http://citforum.univ.kiev.ua/database/po…
Экономия места лишь на уровне индекса, если не меняется поле по которому построен индекс. Плюс не надо ждать вакууминга для повторного использования места, занимаемого версией строки в которой отпала необходимость. Да к тому же все это верно пока версии строки внутри одной страницы памяти. Так что экономия лишь процентная. Если строки большие (много полей), все это хуже работает. Проблема реально остается.
Примеры:
Postgres:
Особенность: на каждый update поля в строке в действительностии добавляется новая строка, старая остается не видимой для сессии.
Это особенность реализации версионности. Поэтому для Postgres'а оптимально разделять таблицы на более мелкие (вертикальное партицирование). Где в одной будут содержаться редко изменяющиеся поля и таких полей может быть много, в другой часто изменяющиеся и таких полей в одной аблице должно быть как можно меньше. Причем таким образом можно делить даже одну сущность (например "корабль"), что уже не верно с точки зрения реляционной теории.
Oracle:
Особенность: Наличие возможности более гибко влиять на построение плана запроса(oracle hints). Что дает возможность лучше подстраиваться под профиль данных и оптимизировать сложные запросы. Можно выбирать решения больше удовлетворяющие реляционным бд, что дает большую гибкость при выборке данных.
Особенность: наличие очень хорошей имплементации bitmap индексов, сущесвенно ускоряющих выборку по однородным данным и уменьшающим обьем хранимых индексов. Это приводит к необходимости создания буферов. Например в буфферные таблицы с разных клиентов складывается информация об изменении координат обьектов, раз в минуту все данные забираются из буферов и append'ом (оракловый метод вставки большого кол-ва строк) вставляются в основное хранилище, что дает оптимальное построение bitmap индексов.
Таких примеров масса. При выборе архитектуры бд надо изходить из возможностей СУБД и профиля данных, но ни в коем случае не из удобства разработки и написания запросов.