Одесса: °С (вода °С)
Киев: 2°С

Тема: Вопрос по проектированию БД

Ответить в теме
Страница 1 из 2 1 2 ПоследняяПоследняя
Показано с 1 по 20 из 21
  1. Вверх #1
    Постоялец форума Аватар для Яр
    Пол
    Мужской
    Адрес
    Odessa.Ua
    Возраст
    30
    Сообщений
    2,952
    Репутация
    148

    Question Вопрос по проектированию БД

    В некотором отношении разрабатываемой БД нужно хранить массив из 512 переменных(назовём - value).
    Элементарного типа данных "массив" в реляционной модели нет (на сколько я знаю).
    Замечание: проблема отягощается тем, что отношение, в котором будут храниться все эти 512 переменных является слабым., (как и несколько его "родителей" -они тоже слабые. Получается в некотором роде иерархия: это отношение однозначно определяется не только своими атрибутами, но и атрибутами родителей).

    На ум приходят следующие способы хранения:

    1) Сериализовать массив и результат добавить в какой-то атрибут отношения.
    Что-то вроде следующего:
    MYTABLE
    pkey1 : INTEGER (PK)
    pkey2 : INTEGER (PK)
    pkey3 : INTEGER (PK)
    serialized_values : TEXT
    Вариант отпадает, как противоречащий первой нормальной форме Бойса - атрибут не атомарен.

    2) для каждого значения value создаётся отдельный экземпляр отношения, номер определяется первичным ключём.

    MYTABLE
    pkey1 : INTEGER (PK)
    pkey2 : INTEGER (PK)
    pkey3 : INTEGER (PK)
    pkeyValueId : INTEGER (PK)
    value : INTEGER
    Здесь проблема в том, что вариант достаточно расточителен . Как упоминалось, отношение слабое, и имеет первичный ключ, состоящий из 3 атрибутов + 1 для идентификации конкретного value. Получается, что всё множество экземпляров отношения занимает уж очень много места. (для каждого атрибута value нужно хранить ещё значения 4 атрибутов первичного ключа).

    3) для каждого значения value создаётся отдельный атрибут одного и того же отношения.

    MYTABLE
    pkey1 : INTEGER (PK)
    pkey2 : INTEGER (PK)
    pkey3 : INTEGER (PK)
    value1 : INTEGER
    value2 : INTEGER
    value3 : INTEGER
    ...................
    ...................
    value254 : INTEGER
    value255 : INTEGER
    По идее, подход лишён недостатков двух предыдущих, но вот, как это будет-то, отношение с 512 атрибутами (+ключи) - это нормально? .

    Извините за кое-где вольную терминологию.
    Пытался изъясниться понятно
    Жду ваших советов. Спасибо за внимание.
    Последний раз редактировалось Яр; 03.12.2006 в 22:39.
    ~ Motivation is what gets you started. Habit is what keeps you going.


  2. Вверх #2
    Не покидает форум Аватар для Ull9
    Пол
    Мужской
    Адрес
    Мюнхен
    Сообщений
    18,454
    Репутация
    1112
    Записей в дневнике
    1
    не совсем понял твою вольную терминологию.
    Что значит слабое отношение? и что значит "В некотором отношении разрабатываемой БД", что такое отношение БД?
    еше неясно "Элементарного типа данных ("массив") нет." почему тип данных массив, элементарный?

    дальше, больше. наверно дело в том что я никогда не проектировал БД.

  3. Вверх #3
    Постоялец форума Аватар для Яр
    Пол
    Мужской
    Адрес
    Odessa.Ua
    Возраст
    30
    Сообщений
    2,952
    Репутация
    148
    Ull9,
    отношение, просто говоря, это таблица. наверно стоило бы сразу так и написать, просто в тех книжках по БД, что я листаю, используется такой термин.

    еше неясно "Элементарного типа данных ("массив") нет." почему тип данных массив, элементарный?
    Я имел в виду, что нет такого типа данных, как массив в реляционных СУБД (на сколько мне известно).

    Под "слабым отношением". (или "идентифицирующей связью") просто говоря, я имел в виду, что экземпляр отношения помимо своих собственных ключей, имеет ещё и ключи его родителей. Т.е дочерняя таблица не может существовать сама по себе, она обязательно зависит от родительской.
    Последний раз редактировалось Яр; 03.12.2006 в 22:34.
    ~ Motivation is what gets you started. Habit is what keeps you going.

  4. Вверх #4
    Не покидает форум Аватар для Ull9
    Пол
    Мужской
    Адрес
    Мюнхен
    Сообщений
    18,454
    Репутация
    1112
    Записей в дневнике
    1
    ок, понятно
    ну если б чего на ц++, то тут я что угодно, можно сказать почти гуру, а БД, извини

  5. Вверх #5
    Постоялец форума Аватар для Яр
    Пол
    Мужской
    Адрес
    Odessa.Ua
    Возраст
    30
    Сообщений
    2,952
    Репутация
    148
    Ull9,

    и на том спасибо ).
    ~ Motivation is what gets you started. Habit is what keeps you going.

  6. Вверх #6
    Ох уж эти теоретики)))
    Сказал бы по-человечески - надо зафигачить массив в таблицу с foreign keys)))
    А я бы сказала - в любом случае хранение массива в базе уже является денормализацией - это раз. Денормализация - не всегда зло - это два.
    Из трех же способов приемлемы два - хранение в виде строки с разделителями, и хранение массива в отдельной таблице со ссылкой на родителя.
    Какой конкретно - зависит от того, ЧТО ты потом планируешь делать с этим массивом.
    Строка - лучший вариант для хранения одномерного массива.
    Таблица - лучший вариант для хранения, сортировки и модификации многомерного массива.
    А вообще - читай Хендерсона, например... и изъясняйся по-человечески)))))
    Не будите во мне Зверя, он и так не высыпается

  7. Вверх #7
    Посетитель Аватар для x[82]
    Пол
    Мужской
    Адрес
    Одесса
    Сообщений
    439
    Репутация
    45
    Насколько я понял нужно хранить n-ое количество массивов, каждый по 512 переменных?
    Если так - 2 таблицы, один-ко-многим.
    Изображения
    • Тип файла: jpg 1.JPG (4.9 Кб, Просмотров: 15)
    I'm GNU/Linux user.

  8. Вверх #8
    Постоялец форума Аватар для Lord of rings
    Пол
    Мужской
    Адрес
    Одесса, типа украина...
    Сообщений
    2,509
    Репутация
    148
    Я сейчас жутко простуженный - нифига не соображаю. Если подождешь дня 2-3 - попробую вникнуть в суть твоей проблемы.
    Per rectum ad astrum!

  9. Вверх #9
    Постоялец форума Аватар для Яр
    Пол
    Мужской
    Адрес
    Odessa.Ua
    Возраст
    30
    Сообщений
    2,952
    Репутация
    148
    Я действительно много напутал в описании, вечером попробую нарисовать схемки, чтобы было понятнее.

    Спасибо всем кто откликнулся,

    Tigra,
    вариант со строкой с разделителями отпадает как непоходящий, потому как нужно иметь возможность обращаться к разным элементам массива из сред, возможно не поддерживающих сложные операции со строками.
    Хранить таблицей - получается что она занимает уж очень много места, потому что у неё выходит 3 первичных ключа + 1 для номера переменной. Сами по себе эти ключи уже весят много больше чем само значение. А ещё, представь, что таких значений сотни, а их количество ещё умножить на 512 значений. Вообщем, вариант не подходит из-за того слишком много весит всё это дело.. + добавление новых значений тоже происходит значительно медленнее.
    Например, там при использовании этого метода выходит 20000 rows для нашей таблицы, вышло бы всего (20000/255 =) 78 при использовании строки с разделителями или большой таблицы с 255 атрибутами.

    x[82],
    вариант с таблицами хорош, но как я уже говорил, в моём случае с тремя первичными ключами + 1 ключ для индексации конкретной переменной массива, на всё это расходуется очень много места.

    Lord of rings, конечно подожду
    Последний раз редактировалось Яр; 04.12.2006 в 08:31.
    ~ Motivation is what gets you started. Habit is what keeps you going.

  10. Вверх #10
    Яр, кстати,а СУБД какая? Некоторые СУБД (не будем показывать пальцами))) являются, скажем так, расширяемыми - т.е. поддерживают пользовательские функции, процедуры и типы данных
    Если твоя - из таких - тогда все совсем хороше.
    Если нет, то -
    что касается
    обращаться к разным элементам массива из сред, возможно не поддерживающих сложные операции со строками
    то массив парсить можно и из SQL. Обращение к отдельным элементам будет идти медленее, но (если хорошо написать), то не катастрофически медленно, конечно.
    Что же касается
    получается что она занимает уж очень много места, потому что у неё выходит 3 первичных ключа + 1 для номера переменной
    то наверное ты еще не видел больших баз)))
    Впрочем, в любом случае решать тебе. Одно скажу - при кажущихся достоинствах вариант со столбцами (атрибутами, ага))) является самым нехорошим с точки зрения дизайна.
    Не будите во мне Зверя, он и так не высыпается

  11. Вверх #11
    Посетитель Аватар для x[82]
    Пол
    Мужской
    Адрес
    Одесса
    Сообщений
    439
    Репутация
    45
    Места пожалуй нормально так займет
    Тогда еще вариант извращения - одна таблица. Все ключи + 512 полей для переменных.
    Я сейчас жутко простуженный - нифига не соображаю. Если подождешь дня 2-3 - попробую вникнуть в суть твоей проблемы.
    Скорейшего выздоровления
    I'm GNU/Linux user.

  12. Вверх #12
    Новичок
    Пол
    Мужской
    Возраст
    35
    Сообщений
    68
    Репутация
    12
    Почему боитесь использовать таблицы с большим количеством строк? Думаете будет медленей работать, чем вы распарсите вручную?
    Сервера БД специально предназначены для оперирования больщими объёмами. Это их работа.
    По поводу, что нет полей типа массив. Есть. В InterBase/FireBird. Точно есть.
    Я бы спроектировал бы по простому. Завёл поле индекс и поле значение. По полю индекс сделал бы индекс (масло масляное, но просто так звучит) - это добавило бы заметно скорости. И решило бы ещё 2 проблемы. Вполне может быть, что некоторые значения будут пустыми - мы их просто в базу не заносим. А если завтра тебе окажеться, что массивы должны быть на 1024 элемента?

  13. Вверх #13
    Посетитель Аватар для x[82]
    Пол
    Мужской
    Адрес
    Одесса
    Сообщений
    439
    Репутация
    45
    Предлагал. Говорит, что места много займет
    I'm GNU/Linux user.

  14. Вверх #14
    Новичок
    Пол
    Мужской
    Возраст
    35
    Сообщений
    68
    Репутация
    12
    Это всё зависит от того, какие поля. Например FireBird умеет буленовские поля ужимать в один бит (при условии, что их много) или блобы тоже жать до одного бита (если блоб равен null)

    Не бойтесь, что база большая. Не пытайтесь "хитро спроектировать" базу, что бы она занимала мало места. Делайте, что бы она работала быстро и не было дублирования данных. И всё будет бегать!

  15. Вверх #15
    Частый гость Аватар для AmonRa
    Пол
    Мужской
    Адрес
    ...есть город, который я вижу во сне...
    Сообщений
    701
    Репутация
    26
    Если БД должна занимать минимум места - пишем в двоичный файл, и получаем максимум быстродействия (при прямых руках).
    Если забить на объем, а также хочется расширяемости и удобства проектирования - выбираем любой SQL сервер
    Wild White Water

  16. Вверх #16
    Частый гость Аватар для AmonRa
    Пол
    Мужской
    Адрес
    ...есть город, который я вижу во сне...
    Сообщений
    701
    Репутация
    26
    Цитата Сообщение от KoVadim
    Это всё зависит от того, какие поля. Например FireBird умеет буленовские поля ужимать в один бит
    Автор не путает Firebird и Interbase? Нет в Firebird логического типа данных. Кроме того сильно не рекомендуется пользоваться типом данных МАССИВ.
    Wild White Water

  17. Вверх #17
    Новичок
    Пол
    Мужской
    Возраст
    35
    Сообщений
    68
    Репутация
    12
    FireBird - продолжение InterBase, который хоть и развивается, но как то слабо.
    IB7 точно имеет буленовский тип, но размер 32 бита. а FireBird - надо дома книгу открыть точно скажу

  18. Вверх #18
    Постоялец форума Аватар для Syon
    Пол
    Мужской
    Адрес
    Одесса
    Возраст
    46
    Сообщений
    1,034
    Репутация
    92
    Записей в дневнике
    1
    А не задумывались уйти от естественных СК к простому искуственному?
    Во многих случаях это вполне безболезненно и более того создает как раз экономию в подтаблицах за счет сокращения накладных расходов на foreign keys. (Если я конечно правильно представил структуру баз)

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

  19. Вверх #19
    User banned
    Пол
    Мужской
    Сообщений
    806
    Репутация
    20
    Скоро исскуственный интеллект станет настолько совершенным, что он будет моделировать естественный

  20. Вверх #20
    Постоялец форума Аватар для Яр
    Пол
    Мужской
    Адрес
    Odessa.Ua
    Возраст
    30
    Сообщений
    2,952
    Репутация
    148
    Всем спасибо!
    буду обдумывать.
    ~ Motivation is what gets you started. Habit is what keeps you going.


Ответить в теме
Страница 1 из 2 1 2 ПоследняяПоследняя

Социальные закладки

Социальные закладки

Ваши права

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