Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум (новые сообщения вниз) Структурный форум

тема: Нормализация базы магазина: стоит ли?

Сообщения:  [1-10]   [11-13] 

 
 автор: Axxil   (13.02.2006 в 15:03)   письмо автору
 
   для: elenaki   (13.02.2006 в 14:58)
 

Тогда естественно не нужна никакя реаляционная БД.
Идеологически (не учитываем скорость) можно было бы текстовым файлом обойтись

   
 
 автор: elenaki   (13.02.2006 в 14:58)   письмо автору
 
   для: Axxil   (13.02.2006 в 14:40)
 

задача была - ежедневное, быстрое и максимально упрощенное выкладывание на сайт прайсов сторонних
организаций. при этом содержание прайсов становилось содержимым e-shop'a (или автоматически после
добавления наценки или после отметки админа). никакой статистики, никакого анализа, никакого хранения.
старые прайсы затираются новыми (вообще-то есть выбор - добавлять или заменять прайс).

   
 
 автор: Axxil   (13.02.2006 в 14:40)   письмо автору
 
   для: elenaki   (13.02.2006 в 14:23)
 

Нет, тут всё ясно...
Эта таблица сродни классической таблице users. Там же мы тоже редко пишем справочную таблицу куда заносим все названия городов или улиц (хотя по идее надо бы :)).
Но у вас наверное задача просто отображать на сайте товары.
А представьте теперь что вам надо работать с производителями. Т.е. например вести учёт поставок, взаимозачётов и т.д. Тгда вы в каждой таблице будете писать название производителя?
>или, допустим, в таблице фирм будет забито 100 (200,300) строк. а прайс на след. день >придет только на одну?
Ну надо бы определится. Если база хранит только мгновенное состояние склада тогда да реляционная база не целесообразна. Аесли нужна история тогда таблица из этих 100,200,300 фирм очень даже пригодится.

   
 
 автор: Axxil   (13.02.2006 в 14:33)   письмо автору
 
   для: elenaki   (13.02.2006 в 13:41)
 

- Так посмотрим таблицу :)

   
 
 автор: Loki   (13.02.2006 в 14:31)   письмо автору
 
   для: elenaki   (13.02.2006 в 14:23)
 

Откровенно говоря, ваша таблица меня напугала даже больше, чем пятитабличный запрос который я недавно составлял.
Но все зависит от задач: допускаю, что при определенных условиях, ваша реализация окажется удобнее. Но я, видимо, все же предпочту реляционные БД.

   
 
 автор: elenaki   (13.02.2006 в 14:23)   письмо автору
 
   для: Loki   (13.02.2006 в 13:46)
 


CREATE TABLE price (
  id varchar(10) default '0',
  price decimal(6,2) default '0.00',  /////////цена оптовая
  offer varchar(30) default NULL, ///////////линк на фотку, в другом магазине - пустое поле, у них фотки по id вызываются
  availab varchar(20) default NULL,  ////////////есть ли товар на складе. наверно, тут хватило бы и одного символа
  famcat varchar(50) default NULL, /////////// family category
  subcat varchar(50) default NULL, /////////// subcategory
  manuf varchar(100) default NULL, ////////// manufacturer
  marka varchar(50) default NULL, /////////// marka
  descr longtext,  //////////// описание товара
  retprice decimal(6,2) default '0.00',  ///////////// розничная цена
  kerdos decimal(4,2) default '0.00', ///////////// наценка (%)
  eshop char(1) default 'N',  ////////// виден ли товар на сайте (тоже только в одном магазине заполняется, в другом видны все товара, у которых установлена наценка)
  apopou varchar(50) default NULL ///////////// поставщик (для организации загрузки прайсов от разных поставщиков)
) ENGINE=MyISAM;



товар можно добавлять и по одному. есть специальная форма. в ней DISTINCT'ом выбираются определенные поля
и строится выпадающий список из них. если в списке нет нужного производителя или марки или еще чего-то,
заполняется текстовое поле с нужным значением. товар заносится, вместе с ним заносится и новый (новые)
производитель(марка и т.д.) и, если нужно занести еще один товар, то в выпадающих списках уже есть все эти
значения.
допустим, админ пошел заносить товар. вдруг видит, что нет нужной фирмы. ему надо оставить форму ввода
товара и идти заносить фирму, потом выбирать ее из списка, вернувшись в форму ввода товара. а если
таких действий много требуется? тут же озвереешь...
а если кто-то умный возьмет и удалит из таблицы производителей строку? а его товар в другой таблице при
этом останется...
или, допустим, в таблице фирм будет забито 100 (200,300) строк. а прайс на след. день придет только на одну? это
не распухание базы?

   
 
 автор: denvor   (13.02.2006 в 13:54)   письмо автору
 
   для: Axxil   (13.02.2006 в 12:51)
 

>А за это вы платили дублированием данных и неоправданным
>распуханием базы. Зачем каждый раз вносить в базу название
>производителя, если можно сделать таблицу производителей и
>пользоваться только их кодами. А представьте название у
>одного изменится... Будете всю базу ворошить и менять
>название?

Так вот я к тому, что на распухание при 2-3 тыс. записей, наверное можно не обращать внимание? А изменение всех на званий тоже просто делается - выберем уникальные значения, выведем их списке формы SELECT и скриптом все поменяем... Я почему иначал эту тему - я пока не вижу серъезных преимуществ нормализованной базы для малых таблиц (неск. тысяч строк). Вот и хочу понять, есть ли они. (Это все, конечно, от двигателя прогресса (лени) - не хочется усложнять скрипты и запросы.)
Для больших - согласен, есть серьезные доводы (размер). А вот для малых? Вот , скажем, 10 производителей, 100 моделей, 10 размеров, 10 цветов

   
 
 автор: Loki   (13.02.2006 в 13:46)   письмо автору
 
   для: elenaki   (13.02.2006 в 13:41)
 

Откровенно говоря, не понял организации таблицы. Не поясните?

   
 
 автор: elenaki   (13.02.2006 в 13:41)   письмо автору
 
   для: Axxil   (13.02.2006 в 12:51)
 

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

   
 
 автор: Axxil   (13.02.2006 в 12:51)   письмо автору
 
   для: elenaki   (13.02.2006 в 12:47)
 

А за это вы платили дублированием данных и неоправданным распуханием базы. Зачем каждый раз вносить в базу название производителя, если можно сделать таблицу производителей и пользоваться только их кодами. А представьте название у одного изменится... Будете всю базу ворошить и менять название?

Нет, реляционная база это ИМХО лучшее на сегодняшний момент решение... Пока XML до конца не доделают...

   

Сообщения:  [1-10]   [11-13] 

Форум разработан IT-студией SoftTime
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования