создание базы

← →
s_karm (2002-11-11 11:32) [0]

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

← →
exit (2002-11-11 11:37) [1]

Читай теорию реляционных СУБД - нормализация БД. Там есть и о преимуществах и о недостатках.

← →
MsGuns © (2002-11-11 13:22) [2]

100 параметров (полей) в одной таблице - это верх маразма (Если только это не показания какой-нибудь сложной диагностики)

← →
NickBat © (2002-11-11 13:44) [3]

>100 параметров (полей) в одной таблице - это верх маразма (Если только это не показания какой-нибудь сложной диагностики)

Да?? А если это развернутая анкета? Не считал, но думаю полей 70 точно набереться.

← →
Jeer © (2002-11-11 13:55) [4]

Вам уже дали совет - читайте теорию реляционных баз.
Впрочем, Кодд возможно не для вас создавал эту теорию.

← →
MsGuns © (2002-11-11 16:16) [5]

Из этих 70 полей анкеты наверняка минимум треть "Да" или "Нет". В таком случае я бы не создавал для каждого ТАКОГО раздела анкеты отдельное поле, но все сказал Jeer. Хотя я видел БД из одной таблицы в 230 полей (dbf). Флаг в руки !

← →
Jeer © (2002-11-11 18:01) [6]

Например, анкета из 70 вопросов-ответов Да-Нет.
1.С одной стороны, искушение ввести в одной таблице 70 bool-полей.
Достаточно просто можно будет делать выборки по заданному критерию.

SELECT * FROM TB WHERE F1=TRUE AND F45=TRUE OR F70=FALSE

Компактно для выборки, громоздко при создании и сопровождении.
Если типы полей не только bool - еще усложняется.

2.Создать 70 таблиц
ID
PAR_ID (ссылка на ответчика)
ANSWER (тип)

Сложнее запрос, но проще модификация, дополнение
Проще создание таблиц с многозначными ответами

3. Создать одну таблицу
ID
PAR_ID (ссылка на ответчика)
ANSWER char(70)

где каждый символ отвечает за свой ответ (до 256 вариантов на один ответ)
Выборка создается через LIKE.

На мой взгляд наиболее компактный вариант, хотя с оптимизацией запросов могут быть проблемы.
Все зависит от размера выборки анкетирования

← →
MsGuns © (2002-11-11 18:59) [7]

>Jeer © (11.11.02 18:01)

Теоретики давно за нас все придумали 8)) В случае множества НЕЗАВИСИМЫХ триггеров используется ВЕС каждого. Т.е. предположим есть 12 ответов типа 0-нет, 1-да. Создаем ОДНО поле Integer

Значение поля Смысл
146 2+16+128 - "Да" на 2, 4 и 8 вопросы

С выборками решение чуть пооригинальнее, но пусть сам думает.

← →
Jeer © (2002-11-11 19:37) [8]

MsGuns © (11.11.02 18:59)
Не спорю, но число "триггеров" в случае целочисленных полей ограничено integer=31, longint=63
Для char больше свободы в числе утверждений и многозначности каждого

← →
MsGuns © (2002-11-11 20:05) [9]

>Jeer © (11.11.02 19:37)

С Вами, конечно, приятно подискутировать, но, похоже, сам товарищ куда-то слинял. Наверное, фигачит таблу из 100 филдов 8))))

← →
Jeer © (2002-11-11 20:18) [10]

MsGuns © (11.11.02 20:05)
Представил и пожалел бедного:))
С сынулей-то утряслось ?

← →
MsGuns © (2002-11-11 20:46) [11]

Все прошло, как с белых яблонь дым. Не обращайте внимания, прошу Вас. Так, было очень паршиво, выпил, ну и понесло козла старого. Постараюсь больше не допускать такого...

← →
s_karm (2002-11-12 11:04) [12]

Всем спасибо (большое), напишу как получится

← →
Sergey13 © (2002-11-12 11:48) [13]

2MsGuns © (11.11.02 18:59)
И чего вы добьетесь этим? Съэкономите 100к дискового пространства? Сумашедший эффект, особенно в эпоху 20-100 гибабайтных винтов! Еще вы получите меньшее время при чтении результата, с этим трудно спорить. Но еще вы получите громадный геморой при интерпретации полученного ответа для нормальной визуализации. И этот геморой будет мучать юзера при каждом обращении к каждой записи. А программиста при написании каждого нового отчета/формы.
Так что решение красивое, но неэффективное. ИМХО

2Jeer © (11.11.02 18:01)
Примерно то-же.
>1.С одной стороны, искушение ввести в одной таблице 70 bool-полей.
Я бы поддался. Обычно самое простое решение бывает самым эффективным. Из опыта.

2s_karm (12.11.02 11:04)
>Всем спасибо (большое), напишу как получится
Красиво ушел не прощаясь. Про анкету то угадали, али нет?

Sergey13 © (12.11.02 11:48)

Всегда важны варианты и идеи.
Жизнь сложнее чем да-нет.
Если s_karm захочется поизучать эффективность того или иного решения - у него будет эта возможность.

>Sergey13 © (12.11.02 11:48)

Да я и не спорю. Просто, ИМХО, так КРАСИВЕЕ. А мне нравится иногда не просто делать, а делать красиво. К тому же при достаточных объемах данных экономия будет не 100Mb, а несколько больше. А по поводу геморроя для программиста-клиента: что мешает все эти выборки вынести в сервер ?

2MsGuns © (12.11.02 12:17)
>Просто, ИМХО, так КРАСИВЕЕ.
Красота - страшная сила. 8-)
>А мне нравится иногда не просто делать, а делать красиво.
Красиво жить не запретишь. Я предпочитаю эффективность. А иногда (не всегда конечно) 100 "некрасивых" строк кода работают в 10 раз быстрее чем 10 "красивых". Хотя красивое я тоже люблю. 8-)
>К тому же при достаточных объемах данных экономия будет не 100Mb, а несколько больше.
Ну, по объемам только отъехавший автор вопроса может судить.
>А по поводу геморроя для программиста-клиента: что мешает все эти выборки вынести в сервер ?
А что, на сервере это все будет само делаться, без программиста? И что, сервер - это ломовая лошадь которую можно грузить пока не загнется? Я за бережное отношение к серверам, их любить и лелеять надо. Тем паче в вопросе стоит Paradox. 8-)

Да и вообще, мне кажется вопрос интерпретирован не совсем так (зациклились на анкете), как задумывал автор (вот блин еще и вопрос за него додумывать!). ИМХО вопрос подразумевал что у некоторой сущности могут быть разные параметры (зависящие от вида сущности) и в этом случае стоит ли их хранить вместе (и тем самым хранить для каждой записи пустые параметры) или разносить по разным таблицам. Ну например клиенты - физические/юридические лица с, ессно, разными атрибутами. Хотя 100 параметров это для этого случая явный пребор 8-).
Если вопрос стоял так, то ИМХО все зависит от планируемых объемов этих сущностей (клиентов в моем примере). Если их будут максимум сотни, то можно и вместе хранить для простоты работы, Если тысячи и более то необходимо раздельное хранение. Хотя, смотреть все надо конкретно в каждом случае.

ЗЫ: А вообще я б таких авторов вопросов ...

>Sergey13 © (13.11.02 09:58)
>ЗЫ: А вообще я б таких авторов вопросов ...

Во-во ! Зонтик им в ж... И там раскрыть !!!!)))))

В одну таблицу кидают только ЛОХИ которые не умеют писать...

создание базы Найти похожие ветки