Добрый день!
Хочу выполнить след задачу:
создать базу данных которая хранит след данные
1)Автомобили+id этого раздела(т.е 2 критерия id и имя)
2)Мебель+id этого раздела
тут нужно осуществить поиск по имени и добавление новых данных на пример "растения"
затем на подобии иерархии
переходим в автомобили
там есть
1)вольво+id этого раздела
2)ауди+id этого раздела
3)VW+id этого раздела
тут нужно осуществить поиск по имени и добавление новых данных на пример "лада"
затем опять иерархия
переходим в ауди:
1)a8 мощность объем id
2)a7 мощность объем id
тут нужно осуществить поиск по имени и добавление новых данных на пример "a4"
так же с Вольво и др. но там другие критерии к примеру мощность и рассход
C бд практически не знаком посоветуйте как осуществить данную задачу. Знаю в делфи вроде есть бд. Посоветуйте среду и парочку книжек по бд к этой среде. Приблизительно знаю как сделать просто базу данных а вот осуществить такую иерархию не знаю как, даже не представляю.
Заранее благодарен.

> Хочу .. базу данных которая хранит
> 1)Автомобили
> 2)Мебель
> нужно добавление .. "растения"


А завтра что ?
Завтра захочешь "продукты" ?
А послезавтра "шмотки" ?
А послепослезавтра "еще черт т е что и сбоку бантик" ?

две таблицы, одна представлена в виде TreeView
вторая - атрибуты ("мощность и рассход")

слева дерево, а, при выборе ветки, справа грид с атрибутами

table Tree
Id_tree
Id_parent

table Attr
id_attr
id_tree
name

id_tree id_parent name
1 0 AUTO
2 0 FLOWER
3 1 VOLVO
4 1 MERSEDES
5 2 ROUSE
6 2 CACTUS

id_attr id_tree name
1 1 AUTO NODE
2 1 ONLY AUTO :)
3 2 FLOWERS NODE
4 2 Buy from us!!
5 6 does not like water
6 6 do not sit down

> вторая - атрибуты ("мощность и рассход")


Особо радует  применение атрибутов "мощность и рассход" к потенциальной категории, к примеру, "нижнее бельё")

ну, тут атрибут абстрактный, только имя :)

если что, можно расширить

table Attr
id_attr
id_tree
name
id_Category

table Category
id_Category
Name

а вообще, напоминает, как ИШ цитировал как-то Кайта,  БД из 4х таблиц
ну а что, зато всё по ТЗ :)

Привлекательную идею и механику реализации задачи ведения масшабируемого номенклатора, сбацаного в Delphi+Firenird, можно подсмотреть, к примеру, у Ашота aka Kaif(с) в продукте Allegro

http://www.gaapinvest.com/allegro/aboutallegro.php
см. п."СПРАВОЧНИКИ: НАСЛЕДОВАНИЕ АТРИБУТОВ, ФОРМАТИРОВАНИЕ НАИМЕНОВАНИЙ"

> СПРАВОЧНИКИ: НАСЛЕДОВАНИЕ АТРИБУТОВ, ФОРМАТИРОВАНИЕ НАИМЕНОВАНИЙ

а..
задачка MonoLif`a реализована
В принципе, к подобному пришел дома, на досуге..
только вот что-то не особо верится, что там все "на лету", как написано в рекламе
это простой документ придется расшифровать минимум за 4-5 соединений..
А если учесть, что все справочники динамические и неограниченно наследуемые - то и больше.
Потом, как написано в полу-рекламе, используется генерированный на лету запрос.
т.е. хранимок нет, движок БД заранее не откомпилил эти 4-5 соединений а то и больше

короче, в "на лету" - "не верю!"

Блин, запросы на custom БД, да еще и "на лету"
имхо, через 2-3 года при нормальном обороте, это будет тормоз еще тот..

хотя..
Если т.н. "срезы на дату" (по аналогу "точку актуальности" желтой программы) делать часто
и грамотно

любая база данных эффективна и компактна всего из двух таблиц:
1) таблица из двух полей: id и наименование.
2) таблица записей, каждое поле которой word (думается мне, что достаточный размер) - ссылка на таблицу 1.

пример, табличная запись стиха
мама мыла
Машу мылом
Маша мыло
не любила

первая таблица:
0 любила
1 мама
2 Маша
3 Машу
4 мыла
5 мыло
6 мылом
7 не

вторая таблица
0 1 4
1 3 6
2 2 5
3 7 0

легко видно, что с увеличением числа записей эффективнось по объему возрастает. мне кажется, что первая таблица не превысит 20 тысяч записей, причем фактически это один столбец, а соответственно идеально сортированный, что офигенно увеличивает поиск.

на такой идеологии у меня даже крутится пара программок, скорость сумасшедшая, главное вовремя остановиться и не поддаваться соблазну разделять слова на приставки, корни, суффиксы и окончания :)

больше всего мне в этом нравится, что механизм перемещения по записям второй таблицы дико простой и наиболее быстрый.

> kilkennycat ©

а можно еще проще - первая таблица это 33 буквы :)

или ее вообще не надо, есть же ASCII таблица
и каждая буква и так имеет код в ней :)

----

а как быть с 3х и более "словными" стихами?
налету альтерить table добавляя очередной столбец FLD_X, который будет сразу nullable, а посему не очень идексированный?

А средний рассказик как записать тогда..
или записать ладно. Как потом получить..  Походу, запрос будет больше рассказика %)

А "войну и мир" - вообще не хватит оперативки на запрос :)

> а как быть с 3х и более "словными" стихами?

все просто,прикидываем примерный наиболее употребительный размер записи. уместилось в одну, хорошо. не уместилось - последний байт = ссылка на продолжение и пишем вторую запись. еще немного и получим винчестер :)

То, что написано в сабже - скорее конец работы с БД, чем начало.
Т.е. когда обследование предмета автоматизации завершено, объекты в деталях описаны, задачи поставлены, средства решения определены

В данном случае, судя по "сказочности" описания, там и конь не валялся.
Типа автор пришел, увидел, победил :)

1С торговля и склад или подобная конфа, справочник номенклатура, туда все описаное можно запихать в любых количествах )

Т.е. делается иерархия - папка(ну вот например автомобили) -> элементы, каждому элементу можно присвоить произвольное количество характеристик ), также есть у каждой папки и элемента код, у элемента еще и артикул )

по аналогии в делфи ну видимо хотя бы 3 таблицы, первая это группы, вторая элементы, третья характеристики ).

Либо даже одна таблица, просто в колонке одной указывать папка это или элемент или характеристика, а также колонку в которой указывать родителя ) короче 1С в тыщу раз проще ))

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

И самое веселое будет это соорудить удобоваримый интерфейс из этих таблиц.

короче чисто по деньгам я щитаю коробка 1С дешевле выйдет, чем если с нуля программистом писать на делфи ) ведь полюбому там еще что то нужно будет со всем этим делать.

> короче чисто по деньгам я щитаю


"щитают" на пальцах, а по деньгам - считают

> [0] 123456789igor ©   (10.10.12 18:10)
> Знаю в делфи вроде есть бд.

В Делфи есть доступ к различным СУБД, сами СУБД отдельно.