0 / 0 / 0
Регистрация: 01.11.2007
Сообщений: 50
1

Разные типы данных в одном поле

20.03.2011, 06:32. Показов 6506. Ответов 23
Метки нет (Все метки)

Предположим, что мне нужно хранить информацию
о человеке в одной таблице. Таблица из двух
колонок: характеристика и ее значение.

Характеристик много, например такие:
Фамилия
Имя
Дата рождения
Рост
Вес
Пол
Цвет волос
Цвет глаз
и т.п.

Нетрудно заметить, что значения по своим типам
для них разные. Вопрос - как описать вторую
колонку (в mySQL)?

Осмелюсь предположить, что универсального типа
данных, позволяющего хранить информацию любого
типа, в mySQL нет.

Можно хранить цифры и даты в формате varchar, но
этого делать не хочется по понятным причинам.
Может кто-нибудь сможет посоветовать мне более
удачный вариант решения подобной проблемы?

Спасибо.
__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь
0
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
20.03.2011, 06:32
Ответы с готовыми решениями:

Разные типы денежных данных в одном поле
Помогите, плиз, не могу сам разобраться. Полазил по инету и не нашел ответа. Есть база с учетом...

Не отображаются разные типы диаграмм на одном графике
Здравствуйте. Собственно, проблему описала уже в заголовке темы. Мне необходимо, чтобы одна...

Как сделать разные типы возвращаемых значений в одном методе
как сделать разные типы возвращаемых значений в одном методе? public static DateTime...

Распарсить строку в разные nullable типы — Decimal И DateTime — в одном операторе
День добрый. Возникла необходимость парсить строку в разные nullable типы - Decimal? и DateTime? -...

23
Airhand
20.03.2011, 16:36 2
Вообше говоря, кроме как строкового, другого варианта объединяющего столько типов не придумаю. А почему не сделать как у всех: ввести поля с нормальными типами?
0 / 0 / 0
Регистрация: 01.11.2007
Сообщений: 50
20.03.2011, 18:04  [ТС] 3
> другого варианта объединяющего столько типов не придумаю

Ну типов не так много. В моем примере их всего три: int, varchar и date.

> А почему не сделать как у всех: ввести поля с нормальными типами?

Именно это и является темой нашего обсуждения
Что считается 'нормальными типами' и где 'ввести поля'?
0
1 / 1 / 3
Регистрация: 03.08.2008
Сообщений: 391
20.03.2011, 19:17 4
не заморачивайся
есть реляционные базы данных
вот и решай вопросы в данной плоскости

я когда то тоже с этим сталкивался
- хранение системных переменных в таблице
- хранение свойств продукции

и начинается геморой...парсинг анализ..и т.д.
0
0 / 0 / 0
Регистрация: 01.11.2007
Сообщений: 50
20.03.2011, 20:34  [ТС] 5
> не заморачивайся
> есть реляционные базы данных
> вот и решай вопросы в данной плоскости

А нельзя ли поподробнее.
Ведь именно в этом и заключается мой вопрос...

> я когда то тоже с этим сталкивался
> - хранение системных переменных в таблице
> - хранение свойств продукции

Это действительно аналогичные примеры.
Так как же решить такую проблему?
0
3795 / 2734 / 631
Регистрация: 08.06.2007
Сообщений: 9,364
Записей в блоге: 4
20.03.2011, 23:36 6
Делается таблица не из двух, а из пяти (например) колонок. В первой характеристика, все остальные могут быть NULL и имеют разные типы. В одной из них хранится значение. Можно добавить еще одну колонку с именем поля, в котором хранится значение. Возможно, использование такой колонки даст эффект в скорости, а может быть и нет.
0
0 / 0 / 0
Регистрация: 01.11.2007
Сообщений: 50
21.03.2011, 13:15  [ТС] 7
> Делается таблица не из двух, а из пяти (например) колонок...

Это неплохое решение, хотя при этом появляется некоторая избыточность, имхо. Но главное, что оно рабочее :-)

У меня появилось еще два своих.

Вариант 1.
Есть таблица с людьми.
Есть таблица с характеристиками:
[№ характеристики][Характеристика][Тип данных]
Создаются несколько таблиц, соответствующих разным типам данных:
[№ человека][№ характеристики][Значение]
Они заполняются в соответствии с типом данных из таблицы с характеристиками.

Вариант 2.
Есть таблица с людьми.
Есть таблица с характеристиками:
[№ характеристики][Характеристика][Тип данных]
Есть таблицы со значениями (!):
[№ значения][Значение]
Они заполняются в соответствии с типом данных значения.
Соединяющая таблица:
[№ человека][№ характеристики][№ Значения или само значен., если int]

Осталось только выбрать лучший вариант из трех.
0
2 / 2 / 1
Регистрация: 04.12.2010
Сообщений: 216
21.03.2011, 18:07 8
Первый вариант из двух твоих.
0
1 / 1 / 3
Регистрация: 03.08.2008
Сообщений: 391
21.03.2011, 19:24 9
Сочувствую когда будешь писать запросы в базу на тему выборки данных...

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

Если было всё так просто то можно бы было всю информацию в базе данных представить в иде 3-4 таблиц...
Компактно. Не правда ли...
Представляешь люди мучатся юзают ...100 - 1000 таблиц...
А оказывается всё можно хранить всего в 3-4.
Всё классно..кроме одного...ОБРАБОТКА ИНФОРМАЦИИ
0
2 / 2 / 1
Регистрация: 04.12.2010
Сообщений: 216
21.03.2011, 19:29 10
Все зависит только от того, как он собирается использовать эти данные. Естественно, база получается не нормализованная. Но я могу понять, что иногда такой подход действртельно может быть удобен.
0
0 / 0 / 0
Регистрация: 01.11.2007
Сообщений: 50
21.03.2011, 23:14  [ТС] 11
2 ogapon

> Сочувствую когда будешь писать запросы в базу на тему выборки данных...

Да, это действительно самое слабое место моих вариантов и в этом отношении вариант palva более удачный.

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

Ну а как же ты решил свои задачи? Не мог бы ты описать структуру своих таблиц?

> Представляешь люди мучатся юзают ...100 - 1000 таблиц...
100 еще можно себе представить... но 1000 не представляю

2 vlgsh

> Все зависит только от того, как он собирается использовать эти данные.

Как обычно. Хранение информации и вывод данных по запросу.

> Естественно, база получается не нормализованная.

У palva нарушена 3НФ, насколько я понимаю...
А в моих вариантах вплоть до 4НФ + НФБК соблюдены. Или я не прав?

> Но я могу понять, что иногда такой подход действительно может быть удобен.

Полностью согласен.
0
2 / 2 / 1
Регистрация: 04.12.2010
Сообщений: 216
21.03.2011, 23:37 12
А как насчет 1НФ?

А когда я спрашивал про использование, подразумевалось, например, для скольких человек ты планируешь получать информацию в одном запросе.

Такой подход оправдан, когда хранишь что-то вроде конфига в BD.

Кстати, а почему ты не можешь завести под каждую из характеристик свое поле в основной таблице? С соответсвующим типом и названием?
Количество характеристик неограничено?
0
TSergey
22.03.2011, 09:00 13
А мне вообще кажется странной некоторая 'зацикленность' автора на типах данных. Может я и не прав, но о типах при проектировании я практически не думаю. Т.е. я конечно ставлю полям типы, но это не главное. При проектировании надо думать о предметной области и будущем удобстве эксплуатации прежде всего. При этом надо помнить и о нормализации конечно, но это не самое главное. ИМХО.

ЗЫ: Для улучшения наглядности проектирования неплохо юзать соответствующие проги а-ля ЕРВИН.
0 / 0 / 0
Регистрация: 01.11.2007
Сообщений: 50
22.03.2011, 10:00  [ТС] 14
> А как насчет 1НФ?

Да вроде все нормально с 1НФ. Значения всех атрибутов во всех примерах атомарны, имхо.

> А когда я спрашивал про использование, подразумевалось,
> например, для скольких человек ты планируешь получать
> информацию в одном запросе.

Мне кажется в данном контексте проще обсуждать проблему
с точки зрения 'хранения технических характеристик товаров'
(тем более это то, что мне и нужно ).
Информацию планирую получать для 10-50 товаров с возможностью
наложения фильтров или сортировки по некоторым характеристикам
(сортировать, естественно, придется общий список из десятков
тыс. товаров).

> Такой подход оправдан, когда хранишь что-то вроде конфига в BD.

Неее, тогда нам нужен другой подход

> Кстати, а почему ты не можешь завести под каждую из
> характеристик свое поле в основной таблице? С
> соответсвующим типом и названием?
> Количество характеристик неограничено?

Сначала я так и думал сделать. Получилось 30 лишних таблиц.
Они были бы не оптимизированы, т.к. не каждая характеристика
для каждого товара была бы заполнена (хотя все было
организованно так, что теоретически это было бы возможно).

Ну и не хотелось бы ограничивать количество характеристик.
Теоретически их количество не ограничено, хотя на практике в
конкретный момент времени их вполне определенное количество
(сейчас их ~350-400).
0
1 / 1 / 3
Регистрация: 03.08.2008
Сообщений: 391
22.03.2011, 13:26 15
Special for Cage....
SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CREATE TABLE t_entity (
 f_pkey INTEGER NOT NULL,
 f_name VARCHAR(50)
); 
 
CREATE TABLE t_type (
 f_pkey INTEGER NOT NULL,
 f_code CHAR(20),
 f_name VARCHAR(50)
);
 
CREATE TABLE t_property (
 f_pkey INTEGER NOT NULL,
 f_fkey_entity INTEGER NOT NULL,
 f_fkey_type INTEGER NOT NULL,
 f_name VARCHAR(50),
 f_value VARCHAR(255)
);
0
1 / 1 / 3
Регистрация: 03.08.2008
Сообщений: 391
22.03.2011, 13:31 16
Обшибся....
SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE TABLE t_entity_type (
f_pkey INTEGER NOT NULL,
f_name VARCHAR(50)
); 
 
CREATE TABLE t_entity (
f_pkey INTEGER NOT NULL,
f_entity_type INTEGER NOT NULL
); 
 
CREATE TABLE t_type (
f_pkey INTEGER NOT NULL,
f_code CHAR(20),
f_name VARCHAR(50)
);
 
CREATE TABLE t_property (
f_pkey INTEGER NOT NULL,
f_fkey_entity INTEGER NOT NULL,
f_fkey_type INTEGER NOT NULL,
f_name VARCHAR(50),
f_value VARCHAR(255)
);
0
1 / 1 / 3
Регистрация: 03.08.2008
Сообщений: 391
22.03.2011, 13:39 17
Последняя коррекция ....
SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
CREATE TABLE t_entity_type (
f_pkey INTEGER NOT NULL,
f_name VARCHAR(50)
); 
 
CREATE TABLE t_entity (
f_pkey INTEGER NOT NULL,
f_entity_type INTEGER NOT NULL
); 
 
CREATE TABLE t_type (
f_pkey INTEGER NOT NULL,
f_code CHAR(20),
f_name VARCHAR(50)
);
 
CREATE TABLE t_property (
f_pkey INTEGER NOT NULL,
f_fkey_entity_type INTEGER NOT NULL,
f_fkey_type INTEGER NOT NULL,
f_name VARCHAR(50)
);
 
CREATE TABLE t_value (
f_pkey INTEGER NOT NULL,
f_fkey_entity INTEGER NOT NULL,
f_fkey_property INTEGER NOT NULL,
f_value VARCHAR(50)
);
0
1 / 1 / 3
Регистрация: 03.08.2008
Сообщений: 391
22.03.2011, 13:44 18
А теперь представь что у тебя есть всего 3 сущности:
- Компании (Код, Имя, КатегорияИД)
- Категории компаний (Код, Имя)
- Продажи по компаниям (Код, КомпанияИД, Дата, Сумма)

и тебе нужно написать запрос в котором предоставить продажи по компаниям с Дата1 по Дата2 по категориям
Категория1, Категория34, Категория56.

В добрый путь....
0
0 / 0 / 0
Регистрация: 01.11.2007
Сообщений: 50
23.03.2011, 14:15  [ТС] 19
2 ogapon

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

Особенно интересно, где здесь хранятся характеристики и где их
значения. Навскидку значения хранятся здесь
> f_value varchar(50)
Если это действительно так, то я бы сослался на свой первый же
пост
> Можно хранить цифры и даты в формате varchar, но
> этого делать не хочется по понятным причинам.

> А теперь представь что у тебя есть всего 3 сущности...

firm(firm_id, firm_name, cat_id)
cat(cat_id, cat_name)
sell(sell_id, firm_id, sell_date, price)

Если я все правильно понял, то ничего сложного я здесь не вижу
SQL
1
2
3
4
5
6
SELECT * FROM sell WHERE
  (sell_date BETWEEN Дата1 AND Дата2) AND
  firm_id IN (
    SELECT firm_id FROM firm WHERE
      cat_id IN (Категория1, Категория34, Категория56)
  );
0
2 / 2 / 1
Регистрация: 04.12.2010
Сообщений: 216
23.03.2011, 15:57 20
Будет работать достаточно медленно. Селект с подселектом всегда медленный. Почему не так:

SQL
1
2
3
4
SELECT s.* FROM sell AS s, firm AS f WHERE
(s.sell_date BETWEEN Дата1 AND Дата2) 
AND s.firm_id = f.firm_id 
AND f.cat_id IN (Категория1, Категория34, Категория56);
??
0
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
23.03.2011, 15:57

Разные типы данных
Нужно выполнить простое вычитание одного слагаемого из другого. Проблема в том, что первое задано...

Шаблон функции и разные типы данных
Как определить переменная какого типа была передана в шаблон функцию ? Например: int или wchar_t*

Интеграция MatLab в C#: разные типы данных
в матлабе реализовал генерацию простого числа, и воспользовался этим в шарпе с помощью следующего...

Размер указателя на разные типы данных
еще один вопрос к етой теме почуму придавая указателю * prt тип short int или double функция sizeof...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.