ЕВА 2000Я делаю из семерки конфетку, вполне стандартными методами. 1С-овский движок БД на своём месте самоё юзабельное и продвинутое средство для разработки и использования. Без всяких там "+ ядро VFP" Нужно просто уметь готовить! И всё!
Выбросите "+ ядро VFP", "весьма нестандартным способом". Задайте стандарты разработки не отступая от майнстрима, напишите документацию, хотя бы в общих чертах и отдыхайте спокойно себе в отпуске. Ваши помощники спокойно всё разрулят! Никаких "возникнут не нужные проблемы" не будет. (сильно подозреваю такой вариант вам не интересен)
Если у вас более 1000 человек на работе и вы считаете з/п на 1С77, то мне было бы интересно обсудить ваш вариант. А так, похоже, что вы сами мало что программируете, в основном «руководите».

ЕВА 2000Опять пальцем в небо. Именно программирую, именно на 1С77. Ухожу от этого, причём не за счет работадателя.
Вы хотите нанять меня чтобы вас проконсультировать? Какие условия предлагаете?
Похоже, вам действительно нечего сказать. Мне ваши консультации не нужны, достаточно, если вы просто «похвастаетесь» своими «достижениями» в 1С77. Но если и это «ноу-хау», то оставьте при себе, когда я опубликую свой код по 1С, посмотрите и скажете, лучше у вас или хуже. Впрочем, я догадываюсь, что вы скажете про это с вашим занудным морализаторством.

maytonЯ так думаю, Emery разрабатывает весьма специализированные системы (скорее всего)
однопользовательского доступа (1 клиент=1 база). Я нечто подобное тоже пописывал,
но сейчас думаю сделал бы по другому.
Я ориентируюсь на стандартный учет на предприятии: начислений / ресурсов / бухгалтерии. Такой учет не может быть монопольным, если речь не идет о сверхмалых фирмах. Многопользовательский режим реализуется как терминал – сервер.

maytonПо поводу собственно идеи.

Я полистал исходники Enery, почитал и понял, что речь идёт о "memory mapping DBF files" для сериализации
состояния некоторых контролов, а также для иммитации работы встраиваемой
СУБД. Насколько я понял, автор развивает эту идею и пропогандирует её для применения в промышленном
масштабе. Если это так - тогда у меня есть несколько вопросов.
Не совсем так. Имеется в виду написать клиента, который сможет, как свободно подключаться к некоторым коммерческим и безплатным серверным БД, так и вообще работать без двигателя. Типа как сделала 1С в версиях 7.7 и 8.х.

mayton1) По сериализации контролов вроде-бы всё ясно. Здесь у меня нет возражений. Далее.
Аспекты иммитации работы СУБД. Как известно современные СУБД используют режим "опережающей
записи" транзакций в специальный кольцевой буфер, который находится на диске. (В MS-SQL
- это просто монотонно растущий файл). В табличные файлы (сегмент данных) грязные строки
(блоки строк) сбрасываются в фоновом "режиме" по таймеру или по достижению контрольных
точек из оперативной памяти. Такой режим работы обеспечивает "мягкую" нагрузку
на диск (только по записи) и обеспечивает 100% возможность воостановления ситемы
после crashdown-s. Этот же режим даёт возможность максимально быстрого update для строк
которые идут не последовательно, а в случайном порядке. (В качестве примера - те цифры которые приводил автор.
200 млн строк проапдейтить по сложному индексу. Априори известно что будут проапдейчены
33% из этого количества и расположены они в сегмента данных абсолютно
случайно. Если применить технологию отображения памяти в файл (вы помните, что я насчитал
6.5 Гигабайт пространства в другом топике) то мы будем постоянно выходить на неоптимальные
операции I/O. Здесь не поможет ни дисковый буфер с его жалкими 16-32Мб, ни технологии TCQ,
т.к объём данных которые надо изменить чрезвычайно велик и расположен неупорядоченно).
Возникает разумный вопрос, насколько глубоко автор реализовал подобные идеи
дисковой оптимизации? Если да - то как? Если нет - то почему? Короче меня интересуют
скорость OLTP и аналитических транзакций. Сюда-же можно добавить вопрос о
восстановлении системы после сбоя класса "отключили питание".

Если автор считает что мой пример с update слишком искусственный - то пускай обоснует.
Вы явно торопите события. Я только в начале пути, чтобы сейчас решать подобные задачи. Пока мои цели проще. Просто переписать на C++ & MFC упрощенное ядро 1С77 и мои собственные конфигурации на нем с максимально возможной потенциальной масштабируемостью. Меня достаточно сильно привлекает режим интенсивного ввода – вывода значительного количества одновременно работающих клиентов. Постепенно я хочу выйти на такую ситуацию. И тогда будут задействованы все идеи, о которых вы упоминаете. Но сначала мне нужна «площадка» для старта в режиме интенсивных нагрузок. Как минимум для этого нужен хороший клиент серверных БД. Вот им мы сейчас и занимаемся. Упоминаемый вами режим работы достаточно интересен и с теоретической точки зрения, так что еще будет время исследовать его поподробнее.

mayton2) Аспекты изоляции транзакций. Как? Можно-ли? Каким образом я могу получить доступ
к такому DBF из multithreaded приложения? Как могу блокировать строку для обновления?
Как раз vfp9t.dll , которую вы не хотите рассматривать и является мультитрэдовой. Прежде чем переходить на стороннюю разработку я хочу некоторое (небольшое) время попрактиковать данные методы «вручную», просто чтобы «прочувствовать» проблему. Если оставаться с «собственным движком», то от «простого» DBF с 4-х байтовой адресацией можно перейти к «расширенному» типа DBFX с 8-ми байтной адресацией. То же касается и ваших вопросов, самостоятельно это можно реализовывать по-разному (исходя из существующего опыта), а используя определенный сервер БД, то исходя из его возможностей.

mayton3) Прочие технические ограничения. Цифры. Сколько можно создать таблиц? Какое макс. количество строк
на таблицу поддерживается? Максимальное количество столбцов на таблицу?
Какой макс. размер сегмента данных (физический объём базы)?
Пока я буду оставаться с библиотекой VFP, то буду связан его ограничениями, которые известны (2 Гб на 1 DBF, 64 Кб на 1 запись – количество полей ограниченно этой величиной). Для собственного DBFX или какого-нибудь промышленного формата эти ограничения можно спокойно обойти. Но мне пока возможностей VFP достаточно.

maytonВарианты с применением библиотек vfp9r.dll / vfp9renu.dll мы рассматривать не будем.
Это неинтересно т.к код "от вендора" и говорить здесь особо не о чём т.к. нет новой идеи.
Я имел в виду vfp9t.dll / vfp9renu.dll . Мне очень нравиться ядро VFP, поэтому я пока буду с ним. Насчет «новой идеи». vfp9t.dll является нестандартным COM-сервером и непосредственно использовать его вы запаритесь. В Google если и есть на это ссылки, то только на меня. Смотрите мои сообщения в теме: http://sql.ru/forum/actualthread.aspx?tid=601874#6466891][VS] Работа с dbf и далее.

miksoftEmerymiksoftДанный код эмулирует лишь один из вариантов выполнения исходного SQL-запроса. Причем не самый оптимальный в случае, когда количество записей в таблицах table_1 и table_2 сопоставимо и велико.Пока это голословное утверждение. Если вы так говорите, то приведите вариант более оптимального решения по аналогии с моим. Количество записей в table_2 не принципиально, поскольку обращение к ним происходит по индексу.Именно, что принципиально. Вам известен алгоритм соединения слиянием?
Ваш алгоритм имеет трудоемкость O(N*log(M)), где N и M - количество записей в первой и второй таблицах соответственно.
Слегка модифицировав алгоритм соединения слиянием, можно получить алгоритм трудоемкостью O(N+M), что при M сопоставимом или большем,чем N, дает значительно меньший рост.
В моем втором алгоритме вторая таблица не присутствует вообще! И не путайте данные, которые уже отсортированы (проиндексированы) и которые еще предстоит отсортировать. Кстати, лучше алгоритма слиянием алгоритм естественным слиянием для частично (или полностью) упорядоченных записей. Для случайных записей – ультрафиолетово.

miksoftНет, там теоретические изыскания. А вы покажите аналог обсуждаемого запроса именно в операциях с DBF и CDX.
В этой теме речь идет исключительно о концепции. Если будете следить за моей серией статей, то рано или поздно дождетесь реализации этой концепции в коде. Данный вопрос слишком объемный, чтобы раскрыть его с пол-пинка,

miksoftВот и покажите "небольшой по объему код" без применения коммерческих движков и бесплатных библиотек.
Со временем покажу, для того и затеял эту канитель с публикацией своих статей. Только для большинства это «напрасный» труд. Если вы тоже так считаете, тогда зачем ждать? :)

maytonEmery, давайте подводить неутешительные итоги. У меня к вам сейчас будет 1 вопрос. Вы собираетесь разрабатывать свою библиотеку (engine, ядро и т.п.) для обобщения ВСЕГО опыта, который вы получили, при разработке/сопровождении множества custom задач поддержки бизнеса и производства?
Нет, не собираюсь. Есть в науке такой метод познания: «от простого к сложному» . Кроме того, что я программист, я еще исследователь программ . Мне важен не самописный клон чужой программы, а желание разобраться в концепции ее работы. Для этого совсем не обязательно моделировать ее 100% функционал. Достаточно смоделировать несколько ключевых процентов . Такому подходу, проникновению в суть вещей, я хочу научить других . Так что все гораздо проще, чем вам всем кажется.

maytonПо моему, вы с изрядной долей фанатизма пытаетесь проникнуть в суть С++-кодинга. При этом вас сильно интересует сам процесс а не результат. Потому-как мне кажется того-же результата можно было-бы достичь более оптимальным путём с точки зрения человек-часов и прочих трудозатрат. Не кажется-ли вам, что ваш метод разработки ПО экономически невыгоден.

И не кажется-ли вам, что вы хотите научить других ... ээ... ну как-бы это сказать.. неправильной идеологии программирования?
Ну, если вам не нравится моя «идеологии программирования», то почему вы думаете, что «неокрепшим умам» она обязательно понравится? Интернет большой и каждый ищет в нем то, в чем видит свою потребность. Что ж вы за всех расписываетесь. Напишите свой цикл статей или книгу с «правильным программированием» и пусть интернетчик выбирает из наших двух опусов, тот, который ему больше нравиться. Мне, например жуть, как не нравится, что наш ребенок обожает пустые бесконечные сериалы ни о чем, если не сказать жестче. Но я не могу на него повлиять и увлечь, скажем, научно-популярными фильмами из Интернета или хотя бы просто научить читать книги. Нет, он твердо предпочитает смотреть «информационный мусор» и совершенно не хочет читать никаких книг, ни хороших, ни плохих. Вот вам и «неокрепший ум»! В школе и ВУЗах тоже ведь учат тому, что в 90% практически не востребовано в жизни. Почему же тогда так «расстраиваться» по поводу нескольких лишних часов потраченных мною на «не нужные» цели? Зачем превращать программирование в ремесло?