Выбор типа базы.

← →
Pavelkq (2004-12-15 13:22) [0]

Здравствуйте! Мне нужно написать программу содержащую данные в которой в одной записи в разных полях может содежаться не равное количество элементов, например вот одна запись:
ID: Элемент: Вид: Город:
1 дом стройка Москва
тележка Питер
сверлить Самара
Т.е. поле ID и Вид содержат по одному элементу, а Элемент и Город несколько. Проблем нет, применяя тип Мемо для поля Элемент и Город, но мне нужно чтобы при сортировке по этим колонкам у меня учитывались прозрачные порядки возрастания, т.е. все элементы считались, как отдельные.
Я вообще-то чайник в базах. Только прочитал пару статей и потыкал лабы по Парадоксовским базам. Было бы здорово поюзать именно эту базу, но не представляю как. Таблица будет всего одна.

← →
Соловьев © (2004-12-15 13:26) [1]

http://www.citforum.ru/database/dbguide/index.shtml
читать и читать.

← →
Sergey13 © (2004-12-15 13:26) [2]

2 Pavelkq (15.12.04 13:22)
> Я вообще-то чайник в базах.
Не обижайся, но это видно и так.

>Только прочитал пару статей и потыкал лабы по Парадоксовским базам.
И что? Решил этим ограничиться?

>Было бы здорово поюзать именно эту базу
В задании к лабе что ли так надо?

← →
Pavelkq (2004-12-15 13:29) [3]

[2] Вовсе не хочу ограничиваться, просто не знаю, нужно ли что-то наворачивать если всего одна таблица.
А делаю это не для лабы, а для себя. В лабых все предельно просто было создать одну табличку и вывести ее. Все шаги были расписаны.

← →
Sergey13 © (2004-12-15 13:46) [4]

2[3] Pavelkq (15.12.04 13:29)
>просто не знаю, нужно ли что-то наворачивать если всего одна таблица.
Так таблица таблице рознь. Можно и с одной гемороя поиметь. Тем более, что мне кажется, что она у тебя одна именно из-за отсутствия опыта.

← →
Pavelkq (2004-12-15 13:57) [5]

Я уже тоже подумал о связанных таблицах... Но тут снова придется связывать один элемент из основной таблицы с несколькими из дочерней. Это возможно?

← →
Sergey13 © (2004-12-15 14:04) [6]

2[5] Pavelkq (15.12.04 13:57)
>Но тут снова придется связывать один элемент из основной таблицы с несколькими из дочерней.
Это как? Одно поле - одна ссылка. Одна запись (много полей) - много ссылок.

← →
Pavelkq (2004-12-15 14:30) [7]

Как чайник могу предположить поворот дочерней таблицы на 90 градусов,т.е. одно поле основной таблицы ведет на соответсвующую запись в дочерней, в которой созданно (с запасом) нужное число полей. Тогда элементы полей (одинакового типа) и будут соответствовать записям. Т.е. получается, что в вертикальной структуре записей основной таблицы имеется соответствие горизонтальной структуре полей дочерней. Как-то коряво сказал, но смысл есть. Не знаю, насколько это реализовано в жизни.
Пока я тут мудрствую лукаво, читаю ссылку от Соловьева. Спасибо!

← →
Sergey13 © (2004-12-15 14:39) [8]

2[7] Pavelkq (15.12.04 14:30)
>Как-то коряво сказал,
Что да, то да. 8-)

>но смысл есть.
Он может и есть, но я лично его не понял. Однако сразу настораживает "созданно (с запасом) нужное число полей". Это, скорее всего, тупик.

Самое простое это проиллюстрировать этот смысл структурой таблиц с примером данных и описаниам связи.

← →
Pavelkq (2004-12-15 14:44) [9]

Можно идею упростить и воплотить, если реализовать все это в ределах одной таблицы. Тогда одна запись превратится в вид:
ID: Элемент1: Элемент2: Элемент3 Вид: Город1: Город2: Город3:
1 дом тележка сверлить стройка Москва Питер Самара

А превратить эту запись в первоначальную уже дело техники. Но как-то извратно:-)

← →
Pavelkq (2004-12-15 14:50) [10]

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

Яснее не стало. 8-)
А словами описАть - что имеется и что надо получить. Только без терминов типа "прозрачные порядки возрастания".

Если все же надо все данные запихать в одну таблицу, то можно итти двумя путями:

1. Линейный.
Создается столько записей, сколько "дочерних" объектов. При этом, естественно, "родительские" объекты повторяются столько раз, сколько у них "деток" (точнее, макс.кол-во из всех типов дочерних объектов).
Преимущество: легко реализуемый поиск, выборка, фильтрация.
Недостатки: никакой нормализации - велика избыточность данных, серьезный объем программирования интерфейса работы с такой таблицей.

2. Псевдоиерархический.
Кол-во записей определяется кол-во "родительских" объектов. Дочерние содержатся с мемополях в виде посортированных (кстати, необязательно) строк.
Преимущество: объем БД существенно меньше, т.к. присутствует нормализация (хоть и в несколько инвалидном виде). Удобно отображать визуально (содержимое мемо легко сортируется "на клиенте" как надо)
Недостаток: Проблемы с поиском и выборкой по "деткам". Как по формированию запросов, так и по времени выборки.

Pavelkq (15.12.04 14:50) [10]

Сильно советую почитать что-нибудь про проектирование БД, в частности - про нормализацию.

← →
Pavelkq (2004-12-15 15:05) [14]

Необходимую структуру записи я описал в самом начале. А сотрировку надо провести так, что если сортирую по полю Город, то все города выстраивались в алфавитном порядке не зависимо от того относятся ли они к одной запили или к разным. Конечного польователя это не должно интересовать. Ему важна правильная сортировка.
Может быть еще представить структуру одной записи по пунктам, где каждый пункт - это одно поле:
1. ID
2. Элемент
2.1. Элемент-1
2.n. Элемент-n
3. Вид
4. Город
4.1. Город-1
4.m. Город-m
И таких записей может быть любое количество. Если без базы данных, то очень легко это описать массивами данных.
А задача такая, есть набор файлов у которых есть различные свойства (внутри). Эти свойства иногда могут быть одиночными, а иногда набором перечислений. Но самих свойств всегда только 5шт. Нужно построить базу (для последующей навигации, сортировки, поска) с удобным интерфейсом, где каждому свойству файла соответствует поле в БД.

← →
Pavelkq (2004-12-15 15:15) [15]

[12]Спасибо, очевидно линейный вариант больше подходит, т.к. если отсортировать по тем же Городам, то поле ID может "разползтизь" по всей таблице (одна запись вначале, другая вконце). Если не сказать, что это один и тот же ID, то будет непонятно что. А так, с линейным методом, все будет наглядно.

Выбор типа базы. Найти похожие ветки