Forum Webscript.Ru
Общие => Базы данных => Тема начата: Serych от 02 Мая 2004, 20:30:59
-
Наверное этот вопрос уже тысячу раз обсуждался. Хочу сделать базу данных, только не знаю как лучше сделать - всё в одной таблице или одну большую таблицу разбить на 5-7 таблиц со схожими по смыслу данными, а потом при select\'e объединять все таблицы в одну и делать выборку? насколько это понизит производительность? мне важна скорость, т.к. посещаемость сайта большая. И ещё такой момент - таблицы будут модифицироваться - добавляться поля.
-
Второй вариант будет удачнее...
-
Serych:
разбить на 5-7 таблиц со схожими по смыслу данными, а потом при select\'e объединять все таблицы в одну и делать выборку?
неправильно
Serych:
таблицы будут модифицироваться - добавляться поля.
неправильно
synthez:
Второй вариант будет удачнее...
неправильно.
-
2 RomikChef
не смешно
-
Serych:
не смешно
правильно.
-
Очень не хочеться, чтобы топик превратился во флейм...
-
Странный человек.
Не хочется - не превращай.
-
Serych:
Хочу сделать базу данных, только не знаю как лучше сделать - всё в одной таблице или одну большую таблицу разбить на 5-7 таблиц со схожими по смыслу данными, а потом при select\'e объединять все таблицы в одну и делать выборку
Или я чего то непонял, или о чем вообще речь?
Если нормализовать базу, то
RomikChef:
неправильно
несогласен.
если нет - то подробности в студию
-
с кем ты не согласен и от кого хочешь подробностей? :-)
и, ээээ.... ты считаешь таблицу, у которой неизвестен состав полей нормализовонной?
совет на этот тред.
не суди по себе, снизь планку.
-
Да, хочу нормализовать базу. Основные поля таблиц известны, то есть структура и понимание того, какая должна быть база, есть. Могут быть введены дополнительные поля в таблицу, не нарушающие структуру, связи и логику базы.
-
Serych
Скользо уже раз писали виликие... но все равно народ никак в толк не возьмет...
Что-бы помочь тебе в составлении структуры твой БД... нужно побробно знать какую информацию ты собираешся хранить в БД, что ты с ней собираешся делать и т.д. ...
Если ты говоришь, что у тебя сильно посещаемый сайт, то тогда вообще стоит отказаться от БД (в обычном представлении)...
Короче такие вопросы с кондачка не решаються... (ДА/НЕТ) обаварианта ответа могут оказаться неправильными...
-
Вот примерно у меня такая ситуация.
На странице выводиться список телевизоров 10-500 (по 50 на странице) штук, и нужно вывести для каждого телевизора его характеристики (30-35 полей) пока сделано всё в одной таблице. Стоит ли разбить характеристики на отдельные таблицы по 6 характеристик (схожих по смыслу) в одной таблице. При выводе всё равно придётся объединять в одну.
-
не удержусь :-)
Serych:
Стоит ли разбить характеристики на отдельные таблицы по 6 характеристик
а еще можно нарисовать перед каждым зеленый квадрат :-)
А вы все - "нормализация, нормализация" :-)
-
Serych
Ну ты сам подумай, если кол-во характеристик намного меньше, чем кол-во моделей телевиоров то стоит, вместо характеристики поставить индекс, хотябы из соображений рациональности использования физического места на диске...
Но в этой ситуайии уместно процитеровать Дональда Кнута:
В преждевременной отпимизации первопричина всех бед...
-
Serych
вот скажи пожалуйста.
нет, я вижу, что у тебя коммуникативные проблемы, но постарайся.
из чего ты исходил? из каких соображений? как тебе повысит производительность разбиение на мелкие таблицы?
или не производительность, а удобство работы?
просто любопытно.
-
Вот ещё поясню, какая БД будет.
Пока есть 35 характеристик телевизора.
Условно я могу разделить их на 5 таблиц по 7 характеристик в каждой. Например:
таблица 1 (электричество)
1) Напряжение: 220В
2) Ток: 1А
..
7) Частота тока: 50Гц
таблица 2 (звук)
1) Стерео
2) Долби
..
7) Автоматическая громкость
..
таблица 7 (входы)
1) Аудио
2) Видео
..
7) Антенна
Как можно видеть значения полей характеристик телевизора могут принимать значение "да" или "нет" - есть такая функция у телевизора или её нет. При выводе это будет "+" или "-"
Дальше я буду выводить на одной странице например 50 моделей телевизоров.
AIWA + + + - + - ... -
SONY + - + + - - ... +
Таблицы будут модифицироватся, т.к. пока есть 35 характеристик, разумеется, что-то будет добавляться/удаляться в процессе развития базы данных. Вот с учётом сказанного делать всё через одну таблицу или через 5 таблиц? Насколько упадёт производительность?
-
прежде, чем задаваться вопросом - насколько упадет производительность, сначала надо задаться вопросом, а зачем вообще делить таблицы? Какой в этом смысл?
Выносить характеристику в отдельную таблицу имеет смысл только тогда, когда характеристика выбирается из набора.
О чем и пишет коммандер, не понимая сути вопроса.
проще надо быть, отвечая на вопросы на форуме. не судить по себе
-
Смысл деления такой - наглядность, понимаемость, простота, удобство. Разумеется, что у меня будет поиск на сайте по характеристикам, поэтому она будет выбираться из набора. То есть например кому-то надо будет посмотреть все телевизоры со "стерео", он нажмёт на ссылку на сайте и ему выведутся все телевизоры со "стерео".
-
не вижу наглядности, понимаемости, простоты, удобства в делении таблицы характеристик на мелкие.
неудобства - вижу. Усложнение запросов.
Serych:
Разумеется, что у меня будет поиск на сайте по характеристикам, поэтому она будет выбираться из набора. То есть например кому-то надо будет посмотреть все телевизоры со "стерео", он нажмёт на ссылку на сайте и ему выведутся все телевизоры со "стерео".
это пример удобства?
а почем он противопроставляется одной таблице? из одной нельзя выбрать стерео?
или к чему этоб было?
-
простота и наглядность в том, что вместо 10 таблиц в базе будет 50?
удобство в том, что вместо унификации поиска по параметру, надо городи ть кучу условий, определяя - из какой таблицы искать?
-
В данном случае вместо 1 большой будет 5 маленькиих. Ок стал потихоньку склоняться к 1 таблице. Но мне интересно действительно ли при создании профессиональных продуктов все делается через 1 таблицу, без разбиения?
-
нет, не все.
однако критерий создания структуры - это связи между данными.
а не раскладывание рюшечек к рюшечкам, а бантиков к бантикам.
базахранитДАННЫЕ. абстрактные.
и связи между ними.
и поскольку база не различает втои критерии, то и ты не должен.
для базы твои критерии- абстрактное поле.
если есть причина вынести абстрактное в другую- выноси.
Если просо для красоты - то тебе надо было в дизайнеры идти, а не в программисты.
-
Serych
create table tv
(
tv_id serial,
model varchar(255),
antena int4,
napriagenie int4,
sound int4,
vixodi int4,
...........
opisanie text,
CONSTRAINT tv_pk PRIMARY KEY (tv_id)
);
create table antena
(
id serial,
name varchar(255),
opisanie text,
.............
CONSTRAINT antena_pk PRIMARY KEY (id)
);
create table napriagenie
(
id serial,
name varchar(255),
opisanie text,
.............
CONSTRAINT napriagenie_pk PRIMARY KEY (id)
);
create table sound
(
id serial,
name varchar(255),
opisanie text,
.............
CONSTRAINT sound_pk PRIMARY KEY (id)
);
create table vixodi
(
id serial,
name varchar(255),
opisanie text,
.............
CONSTRAINT vixodi_pk PRIMARY KEY (id)
);
При такой структуре БД ты можешь иметь не только +/- на против какого-то параметра а набор параметров с четким описанием каждого параметра... но вопрос в том - "НУЖНО ЛИ ТЕБЕ ЭТО?" конечно с одной таблицей (NULL/NOT NULL) оперировать намного проще, если тебе этого достаточно то не забивай себе голову лишними заморочками... если же нет используй структуру подобную вышеописанной...
RomikChef
Слишком много слов.... софистические наклонности это безусловно хорошо, но ты ими только запутываешь человека, не отвечая на поставленный вопрос...
-
[off]
Вообще-то, кто-то не заметил, что поставленный вопрос вообще не имеет смысла.
Вы правда, все странные.
в судите людей по себе. и то, что вопрос бессмысленный- просто не приходит вам в голову.
и вы начинаете ДОГАДЫВАТЬСЯ.
Твой ответ - безусловно,правильный.
вот только к вопросу он не имеет никакого отношения.
чувак не про словари спрашивал.
[/off]
-
RomikChef
ладно оставим это... :)
а то сейчас во флейм передем...:)
-
ты просто стремишься дть обязательно дать практический ответ.
а я считаю, что если человек не понял теорию, то практику ему отвечать бесполезно.
а ты это софистикой счтаешь.
вот уж чем НИКОГДА не занимался.
-
если человек не понял теорию, то практику ему отвечать бесполезно.
Ну это не совсем так... на голой теории далеко не уедешь...
Я стараюсь дать несколько вариантов решения проблеммы, более того не решаю проблемму за человека, а всего лишь показаваю дверь... открыть которую он должен открыть сам...
-
начнем с того, что дверь ты открыл туда, куда вообще не просили.
с тем же успехом ты мог написать о любом совершенно аспекте баз данных
-
RomikChef
Ладно ещё раз призываю давай оставим полемику по этому вопросу... мы уже начинаем переходить на личности... а это не относить к этому топику... если хочешь поприператься создай во флэйме топик "Что я думаю о commander_e..." вот там и поприпераемся... :)