tchingizа еще был парадокс, а к нему был парадокс енжин на си.
Хорошо, буду иметь в виду.

quazareВчера подрубил dbf файл к php движку. особых приимуществ я не заметил.
Сам по себе dbf никаких преимуществ не имеет, разве что прост, хорошо известен и имеет кучу внешних вьюеров. Плюс удобен для обмена данными в С++.

quazareя вообще считаю, что самое правильное - это исходить из соображений трудозатрат. чем меньше времени я потрачу на изготовление программы, тем лучше.
и совершенно неважно, будет ли в качестве бд dbf, sqlite, txt, json, xml, mysql, mssql, postgresql - всеми этими технологиями я владею и буду применять их в зависимости от ситуации...
Я тоже не сторонник садо-мазо. И ориентируюсь, прежде всего на то, что хорошо знаю (до тех пор пока это устраивает меня по производительности). Вообще-то, я планирую использовать интерфейс MFC и ядро VFP для своих бизнес приложений (учетных задач). Решил по этому поводу написать несколько статей. Поскольку все демонстрировалось с нуля, то для начала хотел хранить данные с помощью сериализации (для небольших объемов данных). Однако увидел, фактически сериализация ни чуть не сложнее чем запись в файл БД, например, DBF. Зато вместо последовательного доступа получил произвольный, что мне очень понравилось. Далее, совершенно логично возник вопрос, а почему бы не попробовать сделать и индексный CDX файл? Тем более что до сих пор не приходилось ни разу применять свои знания по сортировке, поиску, деревьям и т.п. в случае непосредственного программирования. А то этим вещам учат программистов, а использовать эти знания негде. Оказалось, что это весьма увлекательное занятие, тем более что сразу обнаружился отрыв теории от практики. Попутно возникла идея попробовать поработать со своей базой данных без SQL запросов, опять же в целях нового опыта, тренировки ума и лучшего понимания этой фундаментальной концепции в серверах БД. Как только я почувствую ограничения такого подхода, сразу перейду на библиотеки VFP или какого-нибудь другого SQL сервера, тем более, что в демонстрационных целях, я планирую делать это параллельно.

maytonВ SQL-технологии (и в частности в sql-engines) заложено очень много возможностей. Версионность, изоляция транзакций. Вы в вашей постановке отказываетесь от этих возможностей?
Да никто не отказывается, просто есть желание попробовать прочувствовать эти вещи, путем их самостоятельного программирования в учебно – познавательно – тренировательных целях. Я уже говорил, чтобы хорошо программировать, программу свою нужно «чувствовать». А чтобы прочувствовать все SQL навороты, нужно попытаться попрограммировать их. Я же веду речь, в общем-то, о демонстрационно-показательном программировании с уклоном на практический результат. Если вам препод по программированию дает задание на первом курсе написать программу вычисления sin(x) или тупейший учет ваших файлов мультимедиа на вашем компьютере для ваших собственных целей, вы же не станете говорить ему, что такие программы уже есть в любом программируемом калькуляторе, или подобный учет и даже круче уже реализован в программе A, B и даже С. Преп, скажет, ну и что мне нужен не результат, как таковой, а ваше умение получить его самостоятельно, проще говоря, уметь умножать не только на калькуляторе, но и вручную. А то, что вы по жизни можете ходить с карманным калькулятором в магазин и перепроверять на нем расчет продавца, его мало волнует. Скажите, а корень квадратный вы сможете вычислить вручную? А ведь в школе этому, по крайней мере, в мое время учили. За всю жизнь я его если пару раз вычислил вне школы, то и хорошо, но ведь вопрос не стоит о том, чтобы не обучать этому в школе. Если хотите, можете воспринимать эту статью, как для школьников, которых учат вручную извлекать квадратный корень. Будут они это делать реально или нет, не важно, важно, что будут иметь об этом представление и уже не поведутся на покупку супер-пуперной программы за килобакс по вычислению квадратного корня для любого целого числа аж до ста!Ьшыешл1537я

битыйЯ привёл Вам решение, которое имело коммерческий успех одно время. Кроме того,прелесть SQL Вы прочувствуете, как только количество пользователей превысит сотню другую.
Я как раз к этому и стремлюсь (спроектировать систему учета на пару сотен пользователей). Жаль только, что на нашей фирме пользователей значительно меньше и трудно прочувствовать эту «прелесть» :) .

ЕВА 2000Т.е. в любом случае вы хотите изготовливать программы на продажу (за деньги), а не для себя, например в учебных или академических целях.
1. Больше 20 активных пользователей на базу ваша технология вряд-ли потянет.
2. Отлаживая движок вы долго с ним провозитесь.
3. Вряд-ли найдете последователей. Когда вам надоест с этим играться, внедрёные бизнес приложения придётся заменять на более майнстримовские.
В результате вы имеете конкуретное отставание, по сравнению с другими внедренцами. Я бы, на свою фирму вас не пустил, с таким подходом к делу.
Да нет, я не планирую брать деньги за свои программы и ее код будет опубликован полностью вместе с пояснением всех принципиальных моментов по самой свободной лицензии.

1. «20 активных пользователей на базу» без привлечения внешних БД весьма неплохой результат. Но опционально я планирую возможность переключаться на некоторые коммерческие и безплатные библиотеки БД.
2. А я никуда не спешу, у меня появилось свободное время, которое «нечем» занять, решил вот получать удовольствие от программирования. Вы имеете возможность для такой «роскоши»?
3. Последователи, как таковые мне не нужны. Я ведь не мессия какой-то! Мне интересен сам процесс общения с профессионалами (не только по программированию). Менять что-либо когда-либо все равно придется, что мои решения, что ваши. Однако мой практический опыт показывает, что есть масса предприятий, которых устроят и мои решения.

Говорить о конкурентном отставании глупо, ибо я живу в провинции, а не в «Силиконовой долине», тут немного другие взгляды на изобретения Майкрософта и иже с ним. В моей нише, так вообще ни «гу-гу», днем с огнем никого не сыщешь. Все ведь ориентируются на «современные» технологии, законодатели мод в которых считанное число фирм – монополистов. Не знаю, какие учетные системы предприятий (недорогие, шустрые, удобные и полнофункциональные) вы имеете в виду, но что-то я не вижу на горизонте ни одной подходящей для нашего предприятия (вполне типичного). Меня брали на работу не как программиста, а как внедренца любой недорогой программы, способной делать все, что нужно нам, а не фирмам производителям. Единственное требование, чтобы я отвечал за работу выбранной программы. Так знаете, я много чё перепробовал и понял, что если не напишу свою программу, именно то, что нужно нашему предприятию, с возможностью расширения, то никогда не смогу гарантировать ее работу при очень скромном бюджете, который мне может быть выделен. Пришлось «покарячиться» некоторое время и я такие программы сделал и внедрил. Все прекрасно работает и вот почему у меня появилось свободное время. Есть ли альтернатива моему решению? Безусловно, только вряд ли оно будет дешевле и стабильнее. Чтобы развиваться дальше, нужно быть на той фирме, чьи потребности ты собираешься удовлетворять. Ибо нюансы всегда есть и сторонние универсальные танковые решения не всегда приемлемы, по разным причинам. А поскольку в нашем городе более крупных организаций почти нет или они уже забиты толпой «программистов», то трудно найти новую «площадку» для дальнейшего профессионального роста. Чтобы не размениваться по мелочам решил пока потусоваться в Интернете до лучших времен. А слишком категоричные работодатели меня тоже не устраивают. Лучше скажите, какую зарплату вы готовы платить тем, кто вам нравиться? :)

ЕВА 2000понравилось, увлекательное занятие, попробовать - Это всё очень замечательное и приятное времяпрепровождение. Но совершенно не коструктивно, если вы собираетесь делать законченные бизнес приложения. Если же, хотите продвигать всё же движок, то нужно выяснить чем он будет лучше остальных движков. "Не использовать SQL" - это не приемущество, а просто глупая блажь, хотя и её уже реализовали. Есть другие приемущества?
Лично я полагаю, что плох тот работник, который не любит свою работу. Работодатель, который «ломает» своего работника через колено – плохой работодатель .
Я хочу, чтобы у моего пользователя всегда был выбор применять велосипедный (или даже реактивный) движок собственной конструкции, либо переключиться на стандартный танковый двигатель (если он у него есть). В этом смысле программа должна быть независима от «двигателя». Преимущество, по крайней мере одно, даже если придется работать с какой-нибудь промышленной БД, восприятие ее после кодирования своего варианта сервера будет более адекватным, за счет чего можно будет получить дополнительную масштабируемость и эффективность. Но реальное решение нужно определять «на месте», в зависимости от возможностей и потребностей предприятия.

MasterZivУвы, хочу тебя огорчить, культ этот обоснован технически. Дело в том,
что в современных приложениях важны две вещи:
-- ACID -транзакции
-- многопользовательских доступ.
Вот эти самые штуки очень плохо делаются в не клиент-серверных архитектурах,
и очень замечательно -- в клиент-серверных архитектурах.
Это все вещи хорошие – для универсальных промышленных серверов. Они ведь «затачиваются» на все случаи жизни. Хотя в обзорах можно прочесть, что те же «ACID -транзакции» хорошо сделаны в Oracle и значительно хуже в MS SQL Server 2005. Так что для компьютерных «религиозных войн» всегда можно найти повод, было бы желание. Но я ведь не корпорация «Майкрософт» и мне нет особой нужды думать решениях на все случаи жизни. Достаточно «удовлетворять» только фирму, в которой работаешь. А уровень требований в разных конторах, как между небом и землей. Где-то программист не устраивает работодателя, где-то наоборот, а где-то есть полюбовное соглашение. Так что всегда найдутся ниши и для файл-сервера и для VFP и для самопальных БД. Спектр потребностей тут непрерывный . Хотя конечно специализацию никто не отменял.

ЕВА 2000Не надо мешать в одну кучу практический результат, в виде бизнес приложений и учебно – познавательное програмирование!!! Это очень плохо кончиться для пары сотен пользователей, когда вас, не дай бог, передет автомобиль.
Знаете конечного бесплатного кода в Интернете опубликовано валом, но мало кто может в нем разобраться. Я пишу конечное приложение с пояснениями как я это делаю, иногда с «лирическими» отступлениями, чтобы продемонстрировать гибкость подхода. Что в этом плохого? Только то, что так еще никто не делал? По крайней мере, я об этом не знаю? Я хочу научить людей делать удочку, а не только ловить рыбу. Если научаться, то я им буду не нужен. Вы по жизни такой придирчивый?

ЕВА 2000Ещё раз повторю, с таким подходом вас до такого количества никто не допустит. (хотя менеджмент наш самый советский, ещё и не такого можно ожидать...)
Я вам тоже повторю, вы слишком категоричный для работодателя, вряд ли это будет способствовать успеху вашей фирмы. Все работники при случае «слиняют».

MasterZivА на кой фиг пользователю-то 6 окон на экране ОДНОВРЕМЕННО ?
Неужели интересны «дела давно минувших дней»? :)
Считаем,
1. Базовое окно (меню / десктоп)
2. Основной список
3. Подчиненный список
4. Следующий подчиненный список
5. Диалог
6. Окно выбора чего-то для поля диалога
Все, лимит исчерпан. Обычно это хватало, но не всегда. У меня были потребности и в 7-м окне. Иногда глючило и на 6-м окне.

ЕВА 2000Реальная жизнь, это не препод по программированию, снимите наконец розовые очки. В реальной жизни от вас требуется только одно умение - получать конкретный, экономически выгодный, результат. Ваш вариант проигрышный со всех сторон, кроме одной - удовлетворение ваших амбиций.
Лично от меня явно никто ничего не требует. Обычно я требую сам от себя. И, как правило, больше, чем от меня неявно ожидают. Иногда приходишь к руководству и говоришь, давайте я вам сделаю еще такой и такой учет. А мне говорят, ну если ТЕБЕ надо, то делай. А лично мне то оно как раз и не надо. Я ведь работаю не в программисткой фирме, а в обычном среднем производственном предприятии. Поскольку я уже с лихвой сделал все, что от меня «неявно ожидали», то могу позволить себе делать то, что мне надо. Так что вы с вашими претензиями явно «не в теме».

tru55Так ведь сортировки могут быть по достаточно большому чилу полей. А индексы - это ведь палка о двух концах. С одной стороны, ускоряют выборку, с другой - удорожают DML.
Значит либо мы делаем кучу индексов для всех сортировок, встречающихся в приложениях, а потом будем после каждого нажатия "Сохранить" идем пить кофе, либо таки придется ждать сортировки. Тем паче, что индекс помогает при сортировке, когда у нас только одна таблица в выборке (что бывает редко), и не факт, что он может помочь при выборке из группы таблиц...
Странно все это слышать. Что мы хотим конкретный учет на конкретном предприятии или собственную универсальную базу данных на все случаи жизни? Я ж веду речь о прогнозируемых ситуациях . А здесь принципиальная «фишка» в том, что используя конкретную структуру и конкретные условия задачи или определенного класса задач можно сильно упростить решение по сравнению с обще-универсальным . А многие пытаются смотреть на предложенные концепции как годящиеся на все случаи жизни.

Мы делаем, не «кучу индексов», а ровно столько сколько нужно, заодно еще и думаем, а можно ли их еще уменьшить без потери функциональности. Насчет выборки данных из группы таблиц это отдельная тема разговора и не предназначенная для решения вообще. Мы ведь делаем не средство разработки, а конечное решение для определенного класса задач с фиксированной структурой данных и запросов . Зная заранее эту фиксированную структуру, можно вести речь об оптимизации и выборе нужного движка БД для нашего клиента.

tru55Отнюдь не все. Если рассмотреть на примере Oracle, то он при full scan читает из таблицы не по одному блоку, а сразу несколько (сколько - задается параметром и возможностями ОС). Поэтому часто даже при выборке 10% записей full scan оказывается эффективнее выборки по индексу (у Кайта есть пример с цифирками). А подобные выборки могут составлять существенную часть. Кроме того, если данных много,существуют и другие методы ускорения помимо индексов, например, секционирование таблиц в Oracle
Все, о чем вы говорите, вполне можно пытаться программировать самим, в том объеме, в котором это необходимо, особенно учитываю стоимость Оракла и его лицензий. Опять же, зная конкретную структуру БД и выборки можно уверено говорить что тогда лучше, full scan, секционирование или индексация.

tru55Так ведь эффективность доступа часто зависит от данных, т.е. от их количества и распределения (равномерное / существенно неравномерное). Т.е. метод доступа, эффективный при одних данных, может перестать быть эффективным при других. Оптимизатор и призван это отслеживать на основе собираемых статистик. А человек? Должен постоянно сопровождать базу и периодически переписывать свои выборки, если начнут поступать жалобы на долгую работу?
Так что утверждение, что пользование оптимизаторами - это "болезнь", вызывает ве-е-есьма существенные сомнения. Так можно вообще отказаться от автоматизации и вернуться к ручной работе (и не только в ИТ)
Мы думаем о разных классах задач, отсюда и «непонятки». Для распределенных БД отдельная песня. Класс задач, который я постоянно имею в виду это типичный учет на предприятии: заработной платы, рабочего времени, ресурсов и конечный бухгалтерский учет. Именно в этих классах задач ощущается повышенная потребность, в тех краях, где я обитаю :) . Если, скажем, предприятие торговое, то будет выбран один подход, производственное – другой. Ибо слишком много специфики в каждом случае. Я не хочу заниматься всеми классами задач одновременно, это неподъемная задача для одного человека. Лучше всего ориентироваться на одно конкретное предприятие с хорошим бюджетом. Однако в рамках этого предприятия нужно делать максимально «широкое» решение.chi22