Roman BrunetsНа счет болтологии не в курсе, но сто тысяч наименований -- это прирост справочника товара в год на не самой большой оптовой книжной базе. Есть варианты засовывать в несколько деревьев (графов)? Если да, то хотелось
бы его услышать. (я серьезно, очень интересно, как без потерь бороться с
такими справочниками)1. Из этих 100тыс. активных максисмум 30-40тыс. Остальное уже скорее всего никогда не появится. Поэтому обязательно нужно внести признак "Выведен из ассортимента".
2. Объединять справочник групп и собственно товары, ИМХО зачастую нерационально. Тем более у групп могут быть свойства, которые неудобно хранить в карточке товара.
Достаточно у товара иметь ссылку на древовидный справочник групп.
Продуманные выборки с учётом различных признаков позволят выбирать только реально необходимый минимум товаров.

sergey888 Поле "номер" широкое, можно вбить раб./дом./моб.
Я думал, что будет хотя бы 2-3 поля под телефоны, а одно широкое поле - самый примитивный вариант решения.
Добустим потребуются все рабочие телефоны директоров - запрос должен будет копаться в этой строке и по каким-то признакам определять, какой из телефонов рабочий...
Я бы не стал утверждать, что такое решение самое правильное и единственно верное, как было сказано ранее.То что примитивный - согласен. Запросто можно сделать поле признака "тип номера" раб/дом/моб. Но тогда придётся учесть, что, придётся приплетать ещё и тел.секретаря, приёмной. Мобильный может быть личным, а может и корпоративным, а то и оба сразу. У него может быть ещё CDMA-телефон и т.п.
Тему можно развить очень широко. А вот стОит ли ?

PVPИ тогда окажется, что предлагаемые вами решения - это тот же подход delphi, назходящийся на более высоком уровне при работе с реляционными базами данных, предназначенный для программиста, работающего с базами данных.Пожалуй, что так. А что тут плохого ? Основная задача подобных систем - заставить разработчика не думать про "системное нутро", а сосредоточится на смысловом коде: запросы, отчёты, формы и т.п.
А вот "...начинать с операций, расчетных таблиц, от продукции, от людей, от подразделеней..." не стОит Это очень узкий взгляд на информацию. А если Вы учитель или строитель или врач ???? На всех не напасёшся абстракций. Поэтому самый универсальный елемент информации - таблицы с полями и записями. В помощью стандартной логики туда можно впихнуть любую информацию, притом так, что найти легко. И научить что где лежит можно любого толкового студента, даже владеющего лишь азами SQL.

Мне например ООП-подход к информации кажется избыточно сложным. Недаром СУБД до сих пор такой штукой не оснащены. ЭТО ПОПРОСТУ НЕРАЦИОНАЛЬНО.
ЗЫ: Только не надо начинать флуд про CACHE и прочие а-ля ООП-СУБД !!!!

sergey888 Запросто можно сделать поле признака "тип номера" раб/дом/моб. Но тогда придётся учесть, что, придётся приплетать ещё и тел.секретаря, приёмной. Мобильный может быть личным, а может и корпоративным, а то и оба сразу. У него может быть ещё CDMA-телефон и т.п.
А почему при проектировании в ERWin Вы этого не учли?Чего "этого" ? Воротить с дополнительными телефонными признаками не было нужды. Всё должно иметь разумную меру. Я просто привёл пример, как можно усложнить казалось бы елементарную единичку информации.

ЗЫ: кончаем офтопить....

Предлагаю завести ряд топиков "САМОПИСКА ХХХХ" где автор(ы) кратко изложит основные концепции системы (технические и идеологические), её преимущества. Предлагаю обязательно там обсудить:

* GUI-концепция, методы навигации, возможности, удобства;
* СУБД-нюансы (СУБД, методы доступа, "где лежит логика?", Х-звенка?, кроссплатформенность);
* Платформа разработки, способы кастомизации (настройки, скрипты, свой АЯ);
* Базовая смысловая функциональность (бух-я, склад, торговля и т.п.).

А также давать ссылки на более полную информацию и документацию. Скриншотами просьба не увлекаться. Начальной инфы не более 2-х экранов.
Просьба расценивать это не как рекламу, а как обмен опытом и достижениями.
Думаю, у общественности есть что показать и чем поделиться.

Как Вам такая идея ? Может создавать эти топики в арии 58 "разработка инф.систем" ?

sergey888Почему бы не сделать универсальную запускалку для DLL и/или Дельфийских пакетов?
В этом случае
1.Не надо изобретать велосипедов
2.Имеется возможность использовать всю Дельфи
3.Можно раздать задания независимым разработчикам и каждый из них будет разрабатывать свою/свои DLL, потом объеденить в один продукт
4.не тебуется перекомпиляция всего проекта при изменении в одном модуле.
5.Возможно писать DLL на разных языках программмирования, что расширяет круг разработчиков.и т.д.Хм.... универсальную не получится. Т.е. сама Делфи и есть эта самая универсальная система.
1. Не всё так просто. Всё программирование - велосипед.
2. Тоже далеко не всё просто.
3. Во многих продуктах так и сделано.
4. Иногда может потребоваться, например при переходе на другую версию IDE;
5. Тут много пессимизма. Вы пробовали создавать DLL со сложным содержимым ?
Даже компиляция на разных версиях может привести к неработоспособности.
Делать проект как один огромный COM-объект и вызовы к нему ? Сложность получится заоблачная и проект будет обречён.

А вот сделать фреймворк, который позволяет удобно манипулировать SQL-запросами и набором конфигурируемых форм вполне посильно сделать.
Многие из нас этим занимались или даже занимаются.
Почему к этому относятся скептически ? Очень мало удачных решений и огромное число неудач.
Цель этого топика - попытаться найти правильный путь, обменяться опытом.