Вообще то в SQL про хранение декларируется только что "If the string to be stored is shorter than the declared length, values of type character will be space-padded; values of type character varying will simply store the shorter string." Все остальное - "Implementation behavior". Но - Корнела я и сам не понял 
Ага, спасибо. Ну по крайней мере все СУБД, с которыми я сталкивался, так делали.
Вот Вы предлагаете множество таблиц типа Камеры, Карты ... - в данной ситуации это очень плохо.
И чем это плохо? Я могу сразу сказать, чем это хорошо. Каждый продукт обладает своими уникальными характеристиками (я дальше буду говорить про компьютерные товары, камеры от меня слишком далеко, но аналоги автор проведёт). У процессора есть частота, количество ядер, производитель, ещё что то. У памяти есть её объём, количество банков, количество планок в комплекте. Хранить всё это в одной таблице если и получится, то ОЧЕНЬ некрасиво.
Завтра мы заведём ещё сотню других товаров - придётся добавлять сотню таблиц -> приехали. И это ещё самая маленькая из проблем! 
Угу, приехали. Вот здесь начинается область, в которой без постановки задачи и мнения заказчика уже ничего не решишь, а можно только предполагать. Я попробую.
Итак:
1. Каждый товар обладает уникальными характеристиками, и их надо отображать в какой-нибудь таблице на сайте (любой сайт приличного компьютерного магазина). Здесь мы либо делаем сто таблиц, либо делаем одну таблицу и к ней делаем таблицу атрибутов. Для простого показа этого хватит, для поиска, фильтрации, сортировки этого не хватит. Т.е. сама постановка предполагает сложную схему и от неё никуда не денешься.
2. Все товары суть одно и то же - название, тип, примечание. В этом случае одной таблицы хватит, я не спорю. Но я не рискнул делать это предположение.
Кстати я так и не понял, в чём проблема сотни таблиц.. Добавляем Java-классы с нужными аннотациями, DDL-ки сами генерируются. При правильной организации проекта это очень просто.
Ваша схема с одной стороны - а) избыточна, а с другой б) не связанна.
Не понял, где избыточность и где несвязанность.
Смотри сам - название таблицы и есть категория (а).
Это ещё почему? Название таблицы это тип товара а не категория. По крайней мере в исходном посте я этого не увидел.
Попробуй мысленно покидать селекты и сразу поймёшь
Не понял. Имеются в виду select-ы для показа дерева? Да, здесь придётся кидать сто селектов, если у нас сто типов товаров. При желании от этого можно избавиться. Ок, следующая попытка:
create table CATEGORY (
ID integer not null primary key
, PARENT integer not null
, NAME varchar(64) not null
<все дополнительные свойства категории>
);
create table PRODUCT (
ID integer not null primary key
, CATEGORY_ID integer not null
, DISPLAY_NAME varchar(100) not null
, PRODUCT_TABLE varchar(20) not null
, PRODUCT_TABLE_ID integer not null
, foreign key CATEGORY_ID references CATEGORY.ID on update restrict on delete restrict
);
create table CAMERA (
ID integer not null primary key
<все дополнительные свойства камеры>
);
create table CARD (
ID integer not null primary key
<все дополнительные свойства карточки>
);
в этом случае правда не получится сделать foreign key-ев и придётся тщательно отслеживать в софте, чтобы база не была в inconsistent state.
В общем мой point такой: разнородные вещи пихать в одну таблицу не нужно без особых на то оснований! я работал с крупной БД, в которой это не соблюдалось. Это просто ужас. Я не хочу, чтобы такое повторялось.
В общем это полиморфная схема, что то вроде
class Category {
Collection<Product> products;
Category parent;
...
}
abstract class Product {
...
}
class Camera extends Product {
...
}
class Card extends Product {
...
}
или по крайней мере она в моей голове моментально возникла в этом виде. А база у нас реляционная. Вот и натягиваем полиморфную модель на реляционную, кто как может.
Войти
Регистрация
Наверх
