Нужно сделать БД-шку среднего ур-ня пользования (основной упор на поиск и сеть).

Проблема такая: могу делать все это просто сам "с нуля" - не так уж сложно, если ограничить универсальность, либо учить специальные БД, тк это задание мне - следствие того, что люди, делавшие оболочку до меня не учли возможности создания другой оболочки.

Таким образом, есть два варианта:
1) Делать самому (проблема та же, что и у предшкственников)
2) Учить что-то распространенное.

Второй вариант не подходит из-за недостатка времени (2-3 месяца). Первый - уже объяснил, легкий, но непрактичный.

Сделать нужно "что бы было", а дорабатывать можно "в итоге". Вариант не достойный, но условия таковы.

А теперь вопрос: какой минимум нужен, что бы сделать базу на том, что ныне распространено (стандарт, или как там) и имеет перспективы в будущем.

Я в теме баз на уровне классической "добавить/удалить/найти" на алгоритмическом (не бд-шном) языке, так что не пинайте за топорность.

Цитата

Денег сколько дашь за разработку ?

Вопрос был конкретный, это не относится, и я не прошу никого ничего за меня делать.
Спасибо, за что есть, но думаю, будут и еще мысли?

Fixin

Цитата

Я в теме баз на уровне классической "добавить/удалить/найти" на алгоритмическом (не бд-шном) языке, так что не пинайте за топорность.

1. Если многопользовательская работа, то без SQL-сервера - никуда. Хочешь не хочешь, а изучить придется. Какой конкретно - от задачи зависит. Традиционно для "толстых" масштабируемых систем с прогнозом непрерывного увеличения объема данных применяют MS SQL/Oracle/DB2. Интернет-системы - mySQL. Ну и т.п.
2. Более неудачного решения, чем на VFP делать клиента - не знаю. Три "плюса" по сравнению с чем угодно:
- клиент весит от 3 Мб (это если ничего не делает, дальше-толще). Для сравнения: у меня толстый клиент весит 2.7 Мб и при этом сам (не сервер) печатает где-то 20 разных документов, экспортирует в Excel и Word несколько форматов таблиц и документов, ну и отображает данные из где-то 50 таблиц (в режиме администратора - около 80);
- все, что сложнее таблицы или строки придется делать ручками и сторонними средствами. Например, дерево выбора отдела на предприятии;
- интеграция по построению отчетности (печати документов) - нулевая, т.е. то что может VFP - не понимает никто. И наоборот - затянуть, например, Word-овский документ в VFP можно, но как только сменится версия Word/Win - приехали. И на другую машину перетаскивать этот импорт/экспорт утрахаешься. Если не поставишь всем VFP.
По крайней мере у VFP 6.0 так. Последний 8-й - не смотрел. Неинтересно.
Да, КАМЕНЬ (поскольку никаких обсуждений не видел):

Цитата

Что касаеться VFP, то это пожалуй лучьшее средство на сегодняшиний день для быстрого создания приложений БД

Угу. Если нужно слепить на коленке 3-5 таблиц и юзать в гордом одиночестве. Т.е. вместо
Excel вполне потянет. Короче студентам лабы делать. Во всех остальных случаях - см. выше.

Еще поправка:

Цитата

MSDE ( бесплатная версия MS SQL Server c ограничением на количестов подлючений юзеров ).

Количество подключений - не ограничено. Ограничен сверху суммарный траффик данных между сервером и клиентами. Это если не по бумажке от M$ судить, а на практике.
Версия не бесплатная: если есть лицензия Офиса (от 2000) - можно применять (он в дистрибутиве Офиса отдельно лежит и отдельно устанавливается - типа замаскировали ). Или отдельно приобретать надо.

Цитата(SergeBS @ 30.12.2005, 13:03)

SQL/Oracle/DB2. Интернет-системы - mySQL. Ну и т.п.

Последнее подойдет для локалки?

Цитата(SergeBS @ 30.12.2005, 13:03)

Более неудачного решения, чем на VFP делать клиента - не знаю

А что предложите взамен?
Добавлено @ 20:51
И еще: как все это клеится с VC и билдером?

Это сообщение отредактировал(а) Fixin - 30.12.2005, 20:50

Цитата(Fixin @ 30.12.2005, 20:50)

Последнее подойдет для локалки?

Да. Но я бы рекомендовал Intebase/Firebird, т.к. эта СУБД более продвинута в техническом плане: триггеры, хранимые процедуры, транцакции и т.д. все это более развито чем в MySQL. Соответсвенно и писать будет легче.
Для C++ Builder-а и Delphi есть несколько хороших компонентов для работы с IB.

Цитата(LSD @ 31.12.2005, 01:45)

Да. Но я бы рекомендовал Intebase/Firebird, т.к. эта СУБД более продвинута в техническом плане: триггеры, хранимые процедуры, транцакции и т.д. все это более развито чем в MySQL. Соответсвенно и писать будет легче. Для C++ Builder-а и Delphi есть несколько хороших компонентов для работы с IB.

Кроме того, из Delphi можно экспортировать в любой Word или Eccel....
Но для этого надо владеть
1) Языком программирования, на котором будете писать клиента (Delphi, C++ Builder)
2) Языком и инструментарием СУБД. В случае Interbase-а это - IBExpert и знание синтаксиса языка СУБД.

Кстати, если с СУБД не выставляется особых требований, то лучше и проще mySQL взять...

Цитата(LSD @ 31.12.2005, 01:45)

Для C++ Builder-а и Delphi есть несколько хороших компонентов для работы с IB.

И, насколько помню, с Делфями/Билдером идёт ограниченная версия Interbase, с которой сразу можно потренироваться.
Как ни крути, но борландовские делфобилдеры - самый "легкоусвояемый" продукт на сей день. Все условия для тягания кнопочек, табличек, списочков, репортов. Т.е. для быстрой реализации бизнес логики на толстом клиенте и и визуализации.
А выбор БД - не суть важно, я так понимаю. Таблички одинаково успешно нашлёпаешь и в IB, и в MS, и в MySQL. Если каких-то супер-претензий и конкретики нету - бери IB. Там же и процедуры с триггерами сможешь добавить по мере надобности.

Не надо ссориться, горячие финские парни .
1. MySQL 5.0 имеет и триггера и хранимки. А транзакции у него в 1900-лохматом году появились. Просто надо знать, что у него может быть 4 разных формата баз. В самом легком транзакций нет. В InnoDB, Berkley - есть. Кстати как временные таблицы юзать то что без транзакций - очень неслабый ход. Тем более что по умолчанию именно в этом формате табличка строится.
2. Зачем InterBase если есть FireBird - то же самое но за бесплатно? И без конфликта с WinXP?
3. Для меня самое неприятное в FireBird: отсутствие Autoincrement полей. А все остальное у нее как у всех остальных. Нет особой разницы.

Цитата(SergeBS @ 10.1.2006, 10:51 )

Для меня самое неприятное в FireBird: отсутствие Autoincrement полей

А это действительно так удобно? Просто я пока работал только с FireBird и Oracle, и нужды в автоинкрементных полях у меня никогда не возникало.

Цитата(Lamer George @ 14.1.2006, 15:16 )

А это действительно так удобно? Просто я пока работал только с FireBird и Oracle, и нужды в автоинкрементных полях у меня никогда не возникало.

В общем конечно можно и обойтись, но правильно спроектированная и нормализованная база данных обычно содержит практически в каждой таблице или автоинкремент или GUID

Цитата(Vit @ 15.1.2006, 04:24 )

GUID

Это что?

У нас обычно триггер + секвенс задействуется. В принципе, то же самое.
Добавлено @ 11:46
Нашел - GUID

Lamer George
[q]
У нас обычно триггер + секвенс задействуется. В принципе, то же самое.
[/q]
Угу. А теперь представь себе, что у тебя 150-200 таблиц. И мастер-детайл. Вот весело-то будет - при каждой вставке по 5-10 триггеров срабатывают... А в ЖарПтице иначе как через триггер и генератор это не сделать. Да еще обратно получить значение - морока. Потому и не нравится.
Насчет автоинкрементных полей - у Т.Тенцера статья была:"Естественные ключи против искусственных ключей". А если проще: чтобы не морочиться с полным перестраиванием индексов при редактировании записи не в пример удобнее иметь это автоинкрементное поле, с его помощью организовывать связи и знать, что главный индекс будет перестраиваться только при удалении записи, а это уж зло неизбежное. Накладные расходы - минимальны. А если еще ввести журналирование с их помощью, то юзер может Иванова превратить в Петрова и т.п. - все равно его злодеяния будут вычислены по этому полю с соответствующими последствиями . Достаточно даже просто регулярные бэкапы делать - и все как на ладони будет. Короче, вещь весьма приятная. У меня без этого поля разве что таблицы-связки для "многие-ко-многим". И то не уверен, что так нормально. Все никак не соберусь потестить.

Цитата(SergeBS @ 16.1.2006, 10:52 )

А если проще: чтобы не морочиться с полным перестраиванием индексов при редактировании записи не в пример удобнее иметь это автоинкрементное поле, с его помощью организовывать связи

Вот это я не совсем понял. А почему нельзя то же самое организовать с помощью механизма "триггер+генератор"? Или ты имеешь в виду, что тогда мы можем редактировать primary key, а в случае автоинкрементного поля - не можем?

Ну, оффтоп попер
А есть статьи по базам, чтоб хотябы представление иметь "обо всем и сразу". Например разъяснение основных терминов и на кой они нужны. Ну так как?

Это сообщение отредактировал(а) Fixin - 16.1.2006, 13:27

Да не то что статьи, а просто талмуды есть.

А самая простая статья вот: http://forum.vingrad.ru/index.php?showtopic=30912
Добавлено @ 14:02
Хотя пардон, ты не это просил. Там только обзор.