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

V>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>От отсутствия реального опыта. Неужели из топика еще непонятно?

V>Там, где справлялся один одинэсник, там надо было 5-10 человек для Паруса, бо всё ручками.
V>Типа как китайцы решат любую задачу, потому что их миллион.

V>Т.е. цимус в том, что как мы студентами эту кучу г-на вывалили, так вы её десятилетиями и обслуживаете.
V>И тут такое вылупилось из яйца и ну давай курицу учить, про свой опыт рассказывать.

Помню, интегрировался я с этим г-ном, долго и упорно. Сотни каких-то непонятных таблиц с непонятными именами... Так вот, кто это оказывается написал..

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

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

V>>Зато безопасность зависит.
V>>Когда у нас доступ к разным таблицам, то можно пользовать родную безопасноть серваков на основе ролей.
V>>А когда речь о доступе к одной и той же, то безопасность тут обеспечивается лишь приложением, но всегда можно приконнектиться в обход приложения и поправить цифирки.
S>Начинаются бесплодные теоретизирования. Доступ на уровне ролей устроен так: если внесение изменений в таблицу "движение", выполняемое совместно с внесением изменений в таблицу

Как человек, очень далекий от подобных учетных систем, хочу спросить — что такое движение? Это по-сути история? То есть как бы перевод средств с одного ордера на другой? При этом сумма средств в ордере обновляется? Или хранится начальное значение, а текущее вычисляется из истории?

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

LP>Помню, интегрировался я с этим г-ном, долго и упорно. Сотни каких-то непонятных таблиц с непонятными именами... Так вот, кто это оказывается написал..

Потому, что у тебя не было Code First и Linq to EF на примере 1С версии 8.3 часть II

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

V>>Т.е. цимус в том, что как мы студентами эту кучу г-на вывалили, так вы её десятилетиями и обслуживаете.
V>>И тут такое вылупилось из яйца и ну давай курицу учить, про свой опыт рассказывать.
LP>Помню, интегрировался я с этим г-ном, долго и упорно. Сотни каких-то непонятных таблиц с непонятными именами... Так вот, кто это оказывается написал..

Ну, всё написать не могли по-определению.
Но "верное" направление задали. ))

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

V>>Ну, всё понятно, внутренний тул выполз наружу.
LP>И взорвал мир. Значит, что-то в нем есть.

Или в самой предметной области ж-па полная творится, что простейшие хранилища типа ключ-значения "взрывают мир".


V>>Там, где надо было 30 узлов на Джаве, там справляется 3 на нейтиве.
LP>Уже три года, как делаются подобные заявления, а до сих пор ничего не родили (production-ready).

Продукт готов 4 года назад, бери да пользуйся.


LP>Все как обычно — на С++ быстро, круто... когда-нибудь. На яве — все работает уже вчера.

Может, ты просто не смог собрать? ))
Там это... надо cmake поставить предварительно.


V>>Т.е. не такая уж моя идея глупая.
LP>Если это — твоя идея, то при чем тут SQL? SQL ни разу под это не ложится.

Идея убежать от динамического SQL в пользу статики.
Потому что сетка стала быстрой, тормза традиционных СУБД наблюдаются во всей красе.

Раньше хоть медленной сеткой маскировались, а теперь получили отвратительное сморщенное голое тельце традионного SQL.

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

LP>>Все как обычно — на С++ быстро, круто... когда-нибудь. На яве — все работает уже вчера.

V>Может, ты просто не смог собрать? ))
V>Там это... надо cmake поставить предварительно.

Я собирал и запускал. Поисследуй статус проекта и отзывы о нем. Оно пока невероятно сырое, все сидят на ява-версии. У меня были периодические падения, аптайм не доходил до 4 часов.

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

V>>Когда у нас доступ к разным таблицам, то можно пользовать родную безопасноть серваков на основе ролей.
V>>А когда речь о доступе к одной и той же, то безопасность тут обеспечивается лишь приложением, но всегда можно приконнектиться в обход приложения и поправить цифирки.
S>Начинаются бесплодные теоретизирования. Доступ на уровне ролей устроен так: если внесение изменений в таблицу "движение", выполняемое совместно с внесением изменений в таблицу "остатки", делается под учёткой пользователя, то он и без приложения может пойти и поправить обе таблицы.

Зачем обычному пользователю давать доступ по записи к таблице движений?


S>В двухзвенной системе у пользователей прав на insert и update на эти таблицы нет, а есть только право выполнения хранимой процедуры.
S>При такой раздаче ролей нам неважно, в скольки таблицах это работает.

Права на хранимую процедуру тоже нет.
Иначе всегда можно отменить проводку, внести корректировку и снова провести.


V>>Да ладно, это чуть ли не норма — делать суррогатные ключи с автонумерацией.
S>Совершенно верно. При этом нет никакой нужды (а зачастую и возможности) знать значение ключа перед вставкой.

Потрясающая некомпетентность. (С)
И про нужду и вдвойне про возможности.


S>Как раз требование "знать значение ещё до вставки" может, в зависимости от используемой СУБД, существенно просадить производительность.

Проседать?
А сделать вот прямо сейчас паузу и подумать?


S>Особенно если избегать делать индекс по этому ключу. Перед тем, как вынимать линейку, надо матчасть выучить.

Со странным упорством натупаешь на одни и те же грабли...
Что, прям ни одной идеи? ))


V>>В этом сама суть ISAM-подхода (на который ты однажды накинулся, ХЗ зачем).
S>Алиса, никогда не повторяй слова только за то, что они умные и красивые.
S>ISAM-подход — он не про то, что индексы обновляются прозрачно. А про то, как расположены записи внутри таблицы — последовательно, фиксированного размера.

ISAM — это способ хранения данных вместе с индексами в одном файле.
Это принципиально.
До эпохи ISAM индексы хранились в отдельном файле.


S>На всякий случай напомню, что в SQL Server никакого ISAM нет
S>а индексы как раз есть, и вполне себе автообновляемые.

Про "автообновляемые" поржал.
ISAM для того и был придуман, чтобы обновлять данные + индексы в рамках одной операции.


V>>А избыточные данные юзверского уровня запросто могут находиться в несогласованном состоянии.
S>Например, full-text индексы, как правило, надо перестраивать вручную. Несмотря на это, их всё ещё называют индексами.

"Вручную" — это самому формировать данные, что ле, ручками? ))
Тебе же сам полнотекстовый индекс не доступен, он прозрачен, его как нет вовсе.
О его наличии можно судить лишь по изменению быстродействия.


V>>Индекс — объект базы данных, создаваемый с целью повышения производительности поиска данных.
S>Совершенно верно. А для чего ты вводил транзитивное замыкание? Уж не для того ли, чтобы ускорить поиск данных?

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

Заметь, как это отличается от твоего полнотекстового недоиндекса, наличие которого не влияет на принципиальную возможность работать с данными (оператор like еще никто не отменял).


V>>Остатки — это "регистры". Даже с учётом вольности терминологии, таки, есть принятое другое название в этой предметной области.
V>>И то и другое индексами не является.
S>Смотря что считать предметной областью. Если RDBMS — то нам ничто не мешает сначала сделать view, которое будет вычислять group by от истории движений, а потом приклеить к нему индекс.
S>И внезапно вместо "регистров", наша штука станет называться "materialized view", или "indexed view", в зависимости от использованной платформы.

Так ты уже замерял как ведёт себя такая схема в сравнении с "ручным" обновлением регистров?
А так-то я могу много подобной дичи подкинуть, за которую будут бить ногами в лицо.


S>Один из частных случаев называется "регистрами". Знать это важно для обсуждения с сотрудникми бухгалтерии (откуда и взят этот термин), но разработчик, претендующий на улучшения существующих СУБД должен понимать, что это — всего лишь частный случай индексированного вью.

Если так вольно рассуждать, то индексом можно назвать всё, что угодно, глупый вышел оффтоп в итоге.


V>>Если есть мотив двигаться на конкретное рабочее место — то надо двигаться.
S>Компания — огромная, я — один. Пока что я двигаюсь от написания кода к принятию продуктовых решений — типа что и когда мы запускаем.

Это движение в противоположном направлении от озвученного ранее желания.


S>Пока что предложения с большим бюджетом в данном треде — только от тебя. Это же ты нам втираешь, что в неспособен написать систему, где отчётность строится по актуальным данным.

Смотри, сейчас тебе придётся оправдываться во лжи. ))

Не жили эти системы на обычном железе при сколько-нибудь накопленных данных.
Ни у кого не жили, что характерно.
Почему одно время и пошла эта тему у меня неплохо.
Не пошло бы — срулил бы поближе к столицам или заграницам. ))

Т.е., судя по твоим ответам, IB и НС ситуация более-менее прорисовывается, а именно — от клиента требуется поставить дорогое железо какое-нить. А у меня вышло 2-3 месяца переписывания "ядра", т.е. однократное переписывание.

Еще элемент твоей лжи в том, что переписывание должно начинаться не тогда, когда уже работать невозможно. Тенденции постепенного увеличения времени отклика становятся заметны задолго до, верно? Времени обычно вагон.

Я же говорю — сильно разный опыт.
Это какая-то другая сторона Луны, натурально.
Сплошной разводняк какой-то...


S>Только хардкор, с закрытием периода, репликацией в OLAP

При том состоянии нашего рынка ПО и при той дикой стоимости доллара?
Разумеется.
Просто напомню (вдруг кто забыл) что серверное железо тогда легко переваливало за 5-10 тыс $$.
И средняя ЗП у людей 150-200 долларов.
А сам бизнес у человека мог стоить 15-30 тыс (для продуктового склада это даже много, даже для большого продуктового оптового склада).

Поэтому вопрос насчёт покупать ли такое безумное железо или купить более грамотный софт — это был даже не вопрос.

А сейчас я читаю тебя и вижу, что ты не понимаешь (или делаешь вид, что не понимаешь), что торговать золотом вагонами или спичками поштучно — это одного и того же уровня IT-задача. И в вашей реальности спичечники ходят лесом. ))


S>и пусть весь мир подождёт, пока мы перепишем всех клиентов.

Клиентам уже можно предлагать комплексные решения. Причём, предлагать более мощное по цене даже дешевле, чем подтюнить их наколенные поделия.


S>Про эксперимент схемы — я всего лишь хотел посмотреть, какие индексы и как будут использоваться. Всё ещё жду схемы недоописанных таблиц.

Не жди, включи воображение.
Принцип я тебе дал целиком, остальное зависит от кол-ва реализованных типов док-тов.
Выбери любые 3-4 вида док-та и огонь.


V>>Еще ты хотел посмотреть на движки работы с таблицами напрямую?
S>Да, было бы интересно. Всё ещё жду ссылки на клиентский интерфейс InnoDB или примеры кода, которые его употребляют.
V>>И да, твои претензии к ISAM от непонимания, вестимо.
V>>Тот же MS SQL — это банальный сервис над ISAM, т.е. непосредственный доступ к данным в данный момент времени имеет только одна программа.
S>(facepalm). Никакого ISAM в MS SQL Server нету и не было никогда. Коллега, не надо так позориться. Ну не знаешь ты, что такое ISAM — спроси, расскажем.

Пока что выяснилось, что нихрена-то ты не знаешь.
Судя по написанному, ты представляешь себе ISAM-файл как простую последовательность записей.
Сколько реальных воплощений ISAM-форматов ты рассматривал?


S>Претензии к нему у нас как раз от глубокого понимания ограничений этого метода хранения данных, по сравнению с page- и extent-based архитектурой.

Во-во.
Получается, что понятия не имеешь, что у большинства ISAM форматов идёт страничная/блоковая организация?
Поэтому, подаёшь всё таким образом, будто идея хранить данные страницами — она уникальная для MS SQL?
Опять пипец на марше. ))

Прикольное вышло обсуждение...
И не только с тобой.
Столько каминаутов спустя 15 лет...

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

LP>Как человек, очень далекий от подобных учетных систем, хочу спросить — что такое движение?

Это способ представления разных данных (из разных таблиц) в однородном виде (в одной таблице).

Здравствуйте, Ночной Смотрящий, Вы писали:

T>>поиск по json полям
НС>А зачем тебе json в БД?

например, набор разнородных параметров, которым не нужна жёсткая структура. например, разобранные поля get-запроса.
можно было бы вынести это в отдельную таблицу, но это дополнительная сущность, дополнительные операции в sql. и если не нужно их постоянно переписывать, то в json они ложатся очень просто.

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

S>В самых простых учётных системах есть крайне популярная штука — star join. Да, там каждая таблица участвует ровно в одной "конструкции join". А вот оптимальный порядок выполнения джойна зависит от конкретного запроса.
S>Если это сложное место непонятно — не стесняйтесь писать, я приведу примеры.

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

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

LP>Не зная того, то дает настоящий современный орм, только и остается биться о стенку.

Ты нам уже продемонстрировал "современный" орм.

LP>Коротко посмотрел на линк. Это дно, это уровень, который ява прошла много лет тому назад.

Дно это List<Object> в качестве результата.

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

V>Зачем обычному пользователю давать доступ по записи к таблице движений?
Не знаю — это была твоя идея. Ты же предлагаешь держать отдельно таблицу остатков, чтобы нельзя было исправить остатки, подправив движение.
V>Права на хранимую процедуру тоже нет.
V>Иначе всегда можно отменить проводку, внести корректировку и снова провести.
Право на отмену проводки — отдельное. Никогда не видел, как в супермаркете кассир кричит "Ключ на кассу пятнадцать!" Это они как раз отмену проводят — для этого начальник смены нужен.

V>>>Да ладно, это чуть ли не норма — делать суррогатные ключи с автонумерацией.
S>>Совершенно верно. При этом нет никакой нужды (а зачастую и возможности) знать значение ключа перед вставкой.

V>Потрясающая некомпетентность. (С)
V>И про нужду и вдвойне про возможности.
Ок, вижу, мы опять подошли к сложному месту. Попробуем объяснить.
Сначала — про возможность. Если мы выбираем целочисленные ключи, то, скажем, в MS SQL нет концепции "генераторов". Identity можно узнать только пост-фактум.
Можно попытаться "угадать" identity, взяв, к примеру, IDENT_CURRENT(). Увы — способ ненадёжен.

V>Проседать?
V>А сделать вот прямо сейчас паузу и подумать?
S>>Особенно если избегать делать индекс по этому ключу. Перед тем, как вынимать линейку, надо матчасть выучить.

V>Со странным упорством натупаешь на одни и те же грабли...
V>Что, прям ни одной идеи? ))
Да все идеи известны ещё позавчера. Select max()+1 — медленно и ненадёжно. Ident_current()+1 — быстро и ненадёжно. GUID — 16 байт вместо 4, уменьшаем количество ключей, влезающих на страницу, замедляем операции.

V>ISAM — это способ хранения данных вместе с индексами в одном файле.
V>Это принципиально.
V>До эпохи ISAM индексы хранились в отдельном файле.
Писец. Нет, ну правдо, писец. Ты бы хоть что-то по теме почитал.
Классический, ну прямо образцовый ISAM — это dBase (foxpro и прочие). Данные — файл .dbf, индексы — файлы .ndx (или .ntx, в зависимости от движка).
В ISAM ты никак в один файл не спрячешь одновременно индекс и данные — там space management примитивнейший. Это и есть его основной недостаток по сравнению со странично-ориентированными хранилищами.
Может быть,в MyISAM что-то сильно умнее сделано? Нет, там индексы хранятся в .MYI — файле.
Вот: https://dev.mysql.com/doc/internals/en/the-myi-file.html. Не благодари.

V>Про "автообновляемые" поржал.
А что, по-твоему индексы в MS SQL надо вручную обновлять?

V>ISAM для того и был придуман, чтобы обновлять данные + индексы в рамках одной операции.
(facepalm). ISAM был придуман как самый простой формат. До него в моде были иерархические базы данных, в которых указатели типа foreign key хранились прямо в данных.
Кодд придумал идею хранить ключи, а чтобы эффективно превращать ключи в смещения и был придуман ISAM — данные отдельно, индексы отдельно.

V>"Вручную" — это самому формировать данные, что ле, ручками? ))
V>Тебе же сам полнотекстовый индекс не доступен, он прозрачен, его как нет вовсе.
V>О его наличии можно судить лишь по изменению быстродействия.
(facepalm) (facepalm) (facepalm).
Пункт один. Чтобы полнотекстовый индекс повлиял на быстродействие, надо заменить

select * from books where body like '%vdimas%'

на

select * from books where contains(body, 'vdimas')

Пункт два — он вовсе не обязательно обновляется сам по себе. Раньше вообще была только ручная мода, сейчас можно включить change tracking, но это предсказуемо замедлит модификации таблицы.
Поэтому, в отличие от обычных индексов, его может потребоваться обслуживать при помощи ALTER FULLTEXT INDEX … START UPDATE POPULATION
V>Нет, не для того. А чтобы сделать этот поиск принципиально возможным.
V>Иерархия отличается от обычной транзитивности тем, что иерархия рекурсивна.
V>И если обычную транзитивность можно восстановить через запрос фиксированной структуры (некоторое кол-во join), то в случае иерархии ты заведомо не знаешь, сколько таких join надо сделать, и ничего ты не восстановишь.
Добро пожаловать в современный SQL с поддержкой CTE. https://technet.microsoft.com/en-us/library/ms186243.aspx. Не благодари.
А до CTE мы это делали при помощи хранимок, которые выполняют тот же закат солнца, что и движок при выполнении CTE, только вручную.
Транзитивное замыкание получается гораздо быстрее — особенно с учётом того, что движок оптимизирует весь запрос. Если внезапно окажется, что предикат на "листья" уж очень селективный, то запрос будет исполняться "снизу вверх", а не наоборот.

V>Заметь, как это отличается от твоего полнотекстового недоиндекса, наличие которого не влияет на принципиальную возможность работать с данными (оператор like еще никто не отменял).
Ну вот опять же, усердная демонстрация невладения предметом.
Ок, давай, изобрази мне вот это на операторе like:

SELECT AddressLine1, KEY_TBL.RANK   
FROM Person.Address AS Address INNER JOIN  
CONTAINSTABLE(Person.Address, AddressLine1, 'ISABOUT ("Bay*,"   
         Street WEIGHT(0.9),   
         View WEIGHT(0.1)  
         ) ' ) AS KEY_TBL  
ON Address.AddressID = KEY_TBL.[KEY]  
ORDER BY KEY_TBL.RANK DESC

Ну, то есть это возможно — но точно так же, как с рекурсиями в до-CTE-шную эпоху. Медленно и печально.

V>Так ты уже замерял как ведёт себя такая схема в сравнении с "ручным" обновлением регистров?
Пока нет. А ты?

V>А так-то я могу много подобной дичи подкинуть, за которую будут бить ногами в лицо.
Ну ведь подкидываешь же, и пока не бьют

V>Если так вольно рассуждать, то индексом можно назвать всё, что угодно, глупый вышел оффтоп в итоге.
Нет, только то, что а) однозначно восстанавливается по исходным данным и б) служит для повышения производительности.

V>Не жили эти системы на обычном железе при сколько-нибудь накопленных данных.
V>Ни у кого не жили, что характерно.
Из твоих знакомых — да. А через нас прошло N+1 заказов.

V>Т.е., судя по твоим ответам, IB и НС ситуация более-менее прорисовывается, а именно — от клиента требуется поставить дорогое железо какое-нить. А у меня вышло 2-3 месяца переписывания "ядра", т.е. однократное переписывание.
Ещё раз: это по твоим ответам надо ставить железо. Т.е. разворачивать OLAP сервер. Потом ещё и настраивать репликацию. Переписывать клиентов с обычного SQL на OLAP. Апгрейдить клиентов.
В нашем случае просто бралась хранимка килобайт на полсотни, переписывалась, тюнились индексы, и волосы становились мягкими и шелковистыми.

V>Еще элемент твоей лжи в том, что переписывание должно начинаться не тогда, когда уже работать невозможно. Тенденции постепенного увеличения времени отклика становятся заметны задолго до, верно? Времени обычно вагон.
Это в идеальном воображаемом мире, где бюджетом управляют программисты. И могут сказать "так, всё, посоны, мои метрики показали скорое наступление финала, будем переписывать".
В реальном мире рулят бизнесмены. Они в своё время заказали "добавить в систему 50 отчётов". Тендер выигрывают индусы (ну а кто ещё?), пишут, сдают.
Отчёты работают. Проходят годы — всё более-менее работает. Айтишники — эксплуатируют. Памяти добавляют, то-сё. Потом, когда уже никак совсем невозможно, ставится вопрос: "надо переделывать отчёты, так нельзя". И через полгода после этого таки выделяют бюджет и ищут контракторов.

А это как раз, например, мы. Приходим и чиним. Да, долго. По паре дней на одну такую индусохранимку. По которой нет ни тестов, ни документации, ни примеров использования. Зато результат есть.

V>Выбери любые 3-4 вида док-та и огонь.
Да там и одного хватит. Ок, посмотрим на днях.

V>Пока что выяснилось, что нихрена-то ты не знаешь.
V>Судя по написанному, ты представляешь себе ISAM-файл как простую последовательность записей.
Совершенно верно. Именно оттуда в нём слово Sequential

V>Сколько реальных воплощений ISAM-форматов ты рассматривал?
Подробно — два. Это ровно на два больше, чем ты

V>Получается, что понятия не имеешь, что у большинства ISAM форматов идёт страничная/блоковая организация?
))
Ну, покажи мне пример ISAM формата со страничной организацией. Вместе посмеёмся.

V>Поэтому, подаёшь всё таким образом, будто идея хранить данные страницами — она уникальная для MS SQL?
Нет, конечно. Все современные движки делают именно так — Sybase/Mysql, Interbase, Oracle, InnoDB, Postresql.

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

V>>ISAM — это способ хранения данных вместе с индексами в одном файле.
V>>Это принципиально.
V>>До эпохи ISAM индексы хранились в отдельном файле.
S>Писец. Нет, ну правдо, писец. Ты бы хоть что-то по теме почитал.
S>Классический, ну прямо образцовый ISAM — это dBase (foxpro и прочие).

Ха-ха.
Так я тебя именно в это и хотел ткнуть на следующей итерации, что все твои представления об ISAM сильно попахивают FoxPro/dBase или Paradox.
Но ты и сам успешно ткнулся. ))


S>В ISAM ты никак в один файл не спрячешь одновременно индекс и данные — там space management примитивнейший.

Всё, расслабься, ты уже показал, что не знаешь, что такое ISAM.
RTFM, потом приходи.


S>Это и есть его основной недостаток по сравнению со странично-ориентированными хранилищами.

Э, нет.
В классике ISAM страничный, со страницами данных, индекса, служебными и страницами переполнений.
Например, Berkeley DB, MS Jet DB, Informix C-ISAM, Superbase, SQLite, MySQL-MyISAM и т.д. до бесконечности — практически все сколь-нибудь популярные.

A C-ISAM index changes automatically whenever a data record changes.

Кароч, твой тон рассуждений об ISAM заставил меня заподозрить кое-какой прикол и спросить тебя прямо.
Ну, всё ясно.
Теперь я лучше понимаю твои "аргументы" из прошлых твоих сообщений, хотя теперь еще меньше с ними согласен. ))

Уверен, что в твое представление не вкладываются даже банальные записи переменной длины (классика ISAM, под записи переменной длины эта технология и была изначально разработана), бо dBase из махрового 80-го года так не умел.

Кароч, ISAM означает доступ к записям через индексы. Противопоставляется SQL-доступу (текстовый запрос), доступу к просто "типизированным файлам" или доступу по физическим ссылкам (непосредственным смещениям данных), как в навигационных базах.

В классике под реляционным SQL всегда лежит что-то вроде ISAM или VSAM.
VSAM — это абстракция над ISAM.

Поэтому, когда я говорил об ISAM, я имел ввиду исключительно библиотечное АПИ для управления записями ISAM-хранилища, т.е. имелся ввиду бэкенд под SQL, бо сам-то SQL не нужен. Но тебе при этом "слышалась" какая-то хрень, сорри.

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

S>Ок, вижу, мы опять подошли к сложному месту. Попробуем объяснить.
S>Сначала — про возможность. Если мы выбираем целочисленные ключи, то, скажем, в MS SQL нет концепции "генераторов". Identity можно узнать только пост-фактум.
S>Можно попытаться "угадать" identity, взяв, к примеру, IDENT_CURRENT(). Увы — способ ненадёжен.

Разумеется ненадёжен и никто так не делает.

Несколько раз мне приходилось генерить ключи самому.
"Приходилось" означает, что другие решения были намного дороже.
И я видел аналогичное тоже не раз.

Оперирование ключами несложное — всё их потенциальное мн-во разбивается на иерархические кластеры, выдача ключей из кластера тривиальна. Пустые места замечательно склеиваются. При незначительном усложнении (если ожидается большой трафик удалений) то удаляемые ключи можно вовсе складывать в отдельный упорядоченный агрегат, каждая попытка записи в который провоцирует операцию слияния его содержимого с пустым пространством соответствующих кластеров. Собсно, так работает любой менеджер оперативной памяти, т.е. самая сложная-навороченная схема выдачи суррогатных ключей по сложности в точности равна менеджеру памяти. А более простая — намного проще.

==============
Вдогонку. Упомянутые алгоритмы управления памятью в данном случае имеют вырожденный случай (т.е. многие ветки алгоритма заведомо отсекаются), бо всегда надо выделять свободный "участок" длиной строго равной 1.

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

G>>>4) Посчитаем мейнстрим-языки, которые умеют цитирование и ad-hoc типы. Я знаю C# и F# (он мейнстримый с натяжкой), оба умеют Linq.
_>>Тут подходят любые статические языки, имеющие элементы метапрограммирования, плюс большинство динамических языков. Т.е. в реальности выбор очень большой.
G>Да-да, назови хотя бы парочку (динамические не интересуют), ну чтобы можно было написать типа такого:
G>

G>from x in t
G>where t.Category.Priority==1
G>select {
G>  StartDate =  x.StartDate.Date,
G>  EndDate = x.StartDate.Date + x.Duration / 24
G>}
G>

G>Тут и проекция, и соединение, и выражения над элементами кортежа. И вообще говоря t не обязан быть ссылкой на таблицу, а может быть запросом.
G>Работа этого кода опирается на возможность цитирования и ad-hoc типы.
G>Покажи аналог на другом языке без ad-hoc типов или цитирования без потери типизированности или выразительности.

Шо, опять?
Я же лично тебе показывал полтора года назад полный пример на C++ (и ниже по ветке)

Автор: Evgeny.Panasyuk
Дата: 06.07.16

.
Ты это, заходи ещё через полтора года, если что.

Здравствуйте, neFormal, Вы писали:
F>предсказуемо это проигнорировали.
F>а я не постесняюсь и попрошу примеров
Ключ к успеху — понимание того, что стоимость исполнения запроса определяется а) объёмом сканируемых исходных данных и б) объёмом промежуточных результатов.
Поэтому важно первым выполнить тот джойн, который сильнее всего ограничит промежуточный результат.
А вот кто сильнее ограничит, даже при одинаковой структуре запроса, может зависеть от значений параметров.
Грубо говоря, ищем заказы группы менеджеров в конкретном городе:

select o.* from orders o 
  inner join managers m on o.managerID = m.Id and m.Supervisor = @Supervisor
  inner join cities c on o.cityId = c.Id and c.Name = @city

Если у нас в параметрах Москва, то, скорее всего, выгоднее сначала делать первый джойн.
Если у нас в параметрах Искитим, то, скорее всего, выгоднее сначала делать второй джойн.

Здравствуйте, vdimas, Вы писали:
V>В классике ISAM страничный, со страницами данных, индекса, служебными и страницами переполнений.
V>Например, Berkeley DB, MS Jet DB, Informix C-ISAM, Superbase, SQLite, MySQL-MyISAM и т.д. до бесконечности — практически все сколь-нибудь популярные.
MyIsam — нет, там space management никакой. Нет ни служебных страниц, ни страниц переполнений. Словом, нихрена там нету.

V>Уверен, что в твое представление не вкладывается даже банальные записи переменной длины (классика ISAM, под записи переменной длины эта технология и была изначально разработана), бо dBase из махрового 80-го года так не умел.
Почему же, вкладывается.
V>Кароч, ISAM означает доступ к записям через индексы. Противопоставляется SQL-доступу (текстовый запрос), доступу к просто "типизированным файлам" или доступу по физическим ссылкам (непосредственным смещениям данных), как в навигационных базах.

V>Поэтому, когда я говорил об ISAM, я имел ввиду исключительно библиотечное АПИ для управления записями ISAM-хранилища, т.е. имелся ввиду бэкенд под SQL, бо сам-то SQL не нужен. Но тебе при этом "слышалась" какая-то хрень, сорри.
Ок, понятно, терминологическая путаница. В нашей деревне под ISAM всегда понимались достаточно конкретные вещи.
Если речь просто об API, который позволяет сделать SEEK или MOVE, то мои возражения — мимо тазика.

На всякий случай напомню, что обсуждение/критика началось не с ISAM вообще, а с MyISAM.
Который как раз не страничный, не блочный, с индексами в отдельном файле, и полным отсутствием поддержки транзакций.
И дело вовсе не в том, что там блокировки — на уровне таблиц, а в том, что там принципиально невозможно сделать update... update... update... update... ROLLBACK!
Некуда откатываться — ведь логгирования нету. "Зато он быстрый", ага.

Здравствуйте, vdimas, Вы писали:
V>Несколько раз мне приходилось генерить ключи самому.
V>"Приходилось" означает, что другие решения были намного дороже.
Ок, давайте теперь поговорим о нужде знать ID ещё до вставки.
Я видел решения, которые устроены примерно так, как ты описал (хотя решительно не понимаю, как там можно оперативно возвращать неиспользованные ключи, не встревая в 2phase commit и прочий хардкор).
В тех случаях, когда я их видел, "необходимость" была продиктована достаточно искусственными причинами.

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

V>К тому же, его как раз было удобно использовать против MS SQL, даже еще до того, как MS SQL был поддержан "официально".
V>ИМХО, официально они его поддержали не правильно. Еще к MS SQL 6.x я коннектился по ODBC, при этом локальная база представляла из себя кеш.
V>А движок MS Jet был примечателен тем, что ему можно было пихать объединённые запросы из внешних и "своих" источников данных — это была та самая мегафишка.
V>Есть ли еще на свете такая система, где я одним запросом достаю удалённые данные и делаю им join с некими локальными? ))
Продолжаем нести свет в массы: да, есть такая система, как минимум одна. Называется MS SQL Server.
RTFMить по словам sp_addlinkedserver.

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

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

LP>>Помню, интегрировался я с этим г-ном, долго и упорно. Сотни каких-то непонятных таблиц с непонятными именами... Так вот, кто это оказывается написал..

S>Потому, что у тебя не было Code First и Linq to EF на примере 1С версии 8.3 часть II

CodeFirst тут не увидел. Базу что-ли создаешь?
Опять не смог понять твой русский код. Не читается оно и все тут.
Ты c таким кодом попробуй в StackOverflow что-то закинуть. А тут и так болшая часть не переваривает, одно это чего стоит: РасширениеДляГуид