|
| |
|
|
| |
для: elenaki
(13.02.2006 в 14:58)
| | | Тогда естественно не нужна никакя реаляционная БД.
Идеологически (не учитываем скорость) можно было бы текстовым файлом обойтись | |
| |
|
|
| |
|
|
| |
для: Axxil
(13.02.2006 в 14:40)
| | | задача была - ежедневное, быстрое и максимально упрощенное выкладывание на сайт прайсов сторонних
организаций. при этом содержание прайсов становилось содержимым e-shop'a (или автоматически после
добавления наценки или после отметки админа). никакой статистики, никакого анализа, никакого хранения.
старые прайсы затираются новыми (вообще-то есть выбор - добавлять или заменять прайс). | |
| |
|
|
| |
|
|
| |
для: elenaki
(13.02.2006 в 14:23)
| | | Нет, тут всё ясно...
Эта таблица сродни классической таблице users. Там же мы тоже редко пишем справочную таблицу куда заносим все названия городов или улиц (хотя по идее надо бы :)).
Но у вас наверное задача просто отображать на сайте товары.
А представьте теперь что вам надо работать с производителями. Т.е. например вести учёт поставок, взаимозачётов и т.д. Тгда вы в каждой таблице будете писать название производителя?
>или, допустим, в таблице фирм будет забито 100 (200,300) строк. а прайс на след. день >придет только на одну?
Ну надо бы определится. Если база хранит только мгновенное состояние склада тогда да реляционная база не целесообразна. Аесли нужна история тогда таблица из этих 100,200,300 фирм очень даже пригодится. | |
| |
|
|
| |
|
|
| |
для: elenaki
(13.02.2006 в 13:41)
| | | - Так посмотрим таблицу :) | |
| |
|
|
| |
|
|
| |
для: 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) строк. а прайс на след. день придет только на одну? это
не распухание базы? | |
| |
|
|
| |
|
|
| |
для: Axxil
(13.02.2006 в 12:51)
| | | >А за это вы платили дублированием данных и неоправданным
>распуханием базы. Зачем каждый раз вносить в базу название
>производителя, если можно сделать таблицу производителей и
>пользоваться только их кодами. А представьте название у
>одного изменится... Будете всю базу ворошить и менять
>название?
Так вот я к тому, что на распухание при 2-3 тыс. записей, наверное можно не обращать внимание? А изменение всех на званий тоже просто делается - выберем уникальные значения, выведем их списке формы SELECT и скриптом все поменяем... Я почему иначал эту тему - я пока не вижу серъезных преимуществ нормализованной базы для малых таблиц (неск. тысяч строк). Вот и хочу понять, есть ли они. (Это все, конечно, от двигателя прогресса (лени) - не хочется усложнять скрипты и запросы.)
Для больших - согласен, есть серьезные доводы (размер). А вот для малых? Вот , скажем, 10 производителей, 100 моделей, 10 размеров, 10 цветов | |
| |
|
|
| |
|
|
| |
для: elenaki
(13.02.2006 в 13:41)
| | | Откровенно говоря, не понял организации таблицы. Не поясните? | |
| |
|
|
| |
|
|
| |
для: Axxil
(13.02.2006 в 12:51)
| | | а мне не нужно редактировать производителей. если он изменится - изменится и вся строка с его товаром.
а как вы себе представляете каждый день загружать прайс с тысячью строк, выбирая при этом отдельные
поля (производителей, марки и т.д.) и занося их в отдельные таблицы (только в случае, если их там еще нет,
а потом подставляя их код в таблицу товаров)? загрузка прайса займет пол-дня. а поиск? пока в таблице
не больше 10 тыс.записей, она не будет сильно тормозить. проверено практикой. | |
| |
|
|
| |
|
|
| |
для: elenaki
(13.02.2006 в 12:47)
| | | А за это вы платили дублированием данных и неоправданным распуханием базы. Зачем каждый раз вносить в базу название производителя, если можно сделать таблицу производителей и пользоваться только их кодами. А представьте название у одного изменится... Будете всю базу ворошить и менять название?
Нет, реляционная база это ИМХО лучшее на сегодняшний момент решение... Пока XML до конца не доделают... | |
| |
|
|
|
