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

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

Таким образом, есть два варианта:
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
Хотя пардон, ты не это просил. Там только обзор.

Lamer George

Цитата

А почему нельзя то же самое организовать с помощью механизма "триггер+генератор"?

Можно. Только в одном случае я при создании таблицы говорю Autoincrement и ни о чем не думаю, а в другом - навешиваю триггер, генератор, и вдобавок еще с получением на клиента значения поля имею хлопоты, а получить надо, иначе свежевставленную запись потеряю. Что проще?

Fixin

Цитата

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

Спроси что попроще. Я просто не помню, что у меня первым было. Давно это было. А если вообще..
Могу посоветовать Райордан "Основы реляционных баз данных", могу -Кириллова и Громова - типа "Основы SQL" и "Принципы построения РБД", как-то так. А самое правильное, наверно - Дейт "Введение в системы баз данных". А чтобы в одной статье "обо всем и сразу" - ну читай Фленова . Он как раз спец по "шпаргалкам для двоечников". Только учти - в его "шпаргалках" ошибки - не случайность, а закономерность.

Цитата(SergeBS @ 16.1.2006, 15:09 )

Можно. Только в одном случае я при создании таблицы говорю Autoincrement и ни о чем не думаю, а в другом - навешиваю триггер, генератор, и вдобавок еще с получением на клиента значения поля имею хлопоты, а получить надо, иначе свежевставленную запись потеряю. Что проще?

1. есть RAD средства которые могут сгенерировать нужные триггеры автоматом.
2. автоинкрементные поля не позволяют делать единую нумерацию в накольких таблицах или БД
3. автоинкрементные поля сами по себе не решают проблемы получения сгенрированных ключей, а даже наоборот создают ее. Стандартный inserrt не позволяет вернуть вставленную строку. И если используя триггер у нас остается возможность прнудительно указывать ключ (вначале генерируем ключ, потом производим inserrt), то используя автоинкрементные поля такой возможности нет.

Цитата(SergeBS @ 16.1.2006, 16:09 )

Можно. Только в одном случае я при создании таблицы говорю Autoincrement и ни о чем не думаю, а в другом - навешиваю триггер, генератор, и вдобавок еще с получением на клиента значения поля имею хлопоты, а получить надо, иначе свежевставленную запись потеряю. Что проще?

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

LSD
По пунктам:
1. Мало ли что есть... Есть и FIBPlus, который это тоже полуавтоматом делает, и IBExpert... И что? "Создадим себе трудности и мужественно их преодолеем"?
2. Приведи пример, зачем нужна сквозная нумерация? Учти: наличие Autoincrement не противоречит 3НФ, а вот сквозная нумерация ...
3. Не знаю, что такое стандартный Insert. У меня в связке MS SQL - ADO никаких дополнительных средств, никаких сквозных нумераций, и проблем с получением ключей нет (свойство - return Autoincrement - default). Так что никакой принудительности, на чисто добровольных началах и с 0 хлопот. Ключ еще какой-то генерить.. Не царское это дело . А вот при попытке перескочить на ЖарПтицу я поимел проблемы. И с Insert и с прочим... Их можно преодолеть - см. п.1. и п.3 (твои). Но нужно ли?

Lamer George

А у меня хранимки только там, где действительно надо - в каскадных удалениях и просчете статистики. Ну еще где-то есть (перенос в архив или перенумерование дела - не помню, смотреть лениво). Потому их немного.
И триггер всего один. Разницу в напряженности работы сервера улови.
Добавлено @ 17:45
LSD
Вдогонку: этак исходя из 3 пункта, заодно и от значений default давай избавимся. Разницы -то никакой .

Репликация, хранение архивных журналов. Вообщем то это можно использовать как аналог GUID, если его самого нельзя использовать по каким либо причинам.


Это тот который

Если ты пишешь приложение которое должно работать с разными базами данных, то никакие специфичные для одной СУБД способы не применимы. Можно опираться только на стандарт, причем тот который поддерживает большинство СУБД. Это нужно например для серверов приложений.


Триггер оставляет свободу выбора разработчику (разрешить вставлять свои значения PK или нет), плюс возможность использовать составные ключи и не числовые ключи (например GUID).

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

LSD

Давай-ка теперь разберемся в терминах: что такое репликация? И что еще за архивные журналы? Тогда и дальше будем говорить.


Угу. Поэтому автоинкремент и имитируют связкой триггер+генератор, а в IBExpert для этого специальная вкладка. Даже статьи на эту тему пишут, тот же Кузьменко, например. Ну не понимают люди, что это только для простых задач. )

Под архивными журналами, я имел в виду таблицы куда скидываются логи работы системы. Как правило у нас они храняться 5-10 лет. И таблицы куда скидываются все строки удаленные из рабочих таблиц. Как правило, это все храниться в отдельной базе.


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


Исходя из наличия данной вкладки, и статьи Кузьменко, делаем вывод. Что автоинкремент, единсвенно верный путь генерации ключа. Раз его "все" пытаются эмулировать, даже те базы которые по убогости своей его не имеют.

LSD

Совпадает полностью с replication в MS SQL (там даже больше). Соответственно там сквозная нумерация не нужна, поскольку уже есть весь механизм репликации. А в FireBird полей autoincrement нет, соответственно и проблем с назначением на сервере-реплике того же значения, что на мастере, нет. Только я не назвал бы это сквозной нумерацией. Это просто копии записей. Никаких дополнительных нумераций нет.
Да, давно тому назад заимел статью Уфимцева "Сервис многократного 'UNDO' в многопользовательской системе, построенной на основе MS SQL-server 7.0". Если склероз не изменяет, то убрав само восстановление, получаем журналирование. Если интересно, могу закинуть. Реализуется практически без затрат на программирование. Несколько SP делают для базы все что надо. 4 дополнительных таблички.


Насчет "единственно верный" - я такого не говорил. Но вот удобен очень.

При репликации проблема в том, как обеспечить уникальность первичных ключей при добавлении записи и как втавить запись с указанным ключем. Первую проблему обычно решают используя GUID, но если он не доступен то sequence с шагом N способен его заменить. При использованнии триггеров, вторая проблема решается проверкой было ли явно указано значение первичного ключа.

Если статья применима не только к SQL Server, то закинь.

Не вижу никаких трудносте при использовании генераторов...
Если я работаю через dbКомпоненты то указываю generatorField. Если же по каким-то причинам я напрямую (через Insert into) добавляю запись, то я прямо в insert into вызываю генератор....
ИМХО, генератор - более гибкое средство, чем автоинкремент.

YurikGL
Ну сколько можно... Я не утверждал, что генератор хуже/лучше автоинкремента. Кто хочет с генераторами - да пусть, я не возражаю. Просто когда автоинкремента достаточно, и он в наличии, это быстро и удобно. И никаких dbКомпонент не надо (наверно все-таки IB ).

>fixin
>могу делать все это просто сам "с нуля" - не так уж сложно

Смелое заявление Ты с одними ... все молчу... Не даром люди за ето такие бабки ломят. Я сам так думал 5 лет назад.
А сейчас вопросы задаю.