leonid26

Да... именно необходимо сравнение строк с числом... база товаров импортируется и у id групп именно строки, а в моей базе id групп это числа.

mysql> SELECT *, g.id FROM `products` AS p LEFT JOIN `groups` AS g ON p.group_id = g.id WHERE g.id IS NULL; Empty set, 2637 warnings (0.19 sec) mysql> SELECT title FROM products AS p WHERE NOT EXISTS (SELECT id FROM groups WHERE id = p.group_id); Empty set, 2637 warnings (0.02 sec) Конкретно таблицы выглядят так: create table products ( id int not null primary key auto_increment, group_id char(6) default 0, title varchar(256) not null, stok char(6), price float not null, pdate timestamp, provider int not null ) ENGINE=MyISAM DEFAULT CHARSET=cp1251; create table groups ( id int not null primary key auto_increment, title char(128), parent int not null default 0 ) ENGINE=MyISAM DEFAULT CHARSET=cp1251;

Есть две таблицы: create table groups( id int, title char(64) ); create table products( group_id char(6), title char(64) ); Таблицы максимально упрощены. Необходимо из таблицы products извлечь все записи для которых не найдено группы в таблице groups Моё решение: select title from products where group_id not in (select id groups); возвращает неверные данные, а именно - если у есть группа с id 2 то ни одна запись из таблицы products содержащая 2 в group_id не будет возвращена.... подскажите варианты выхода их положения.

Ещё момент. Просто набираюсь практического опыта Есть строки меню, а-ля: Заголовок;Ссылка;Уровень доступа. Соответственно для каждого уровня показываются ссылки доступные только ему. Смысл держать это меню в файле и парсить php следующий: меню меняется не часто, точнее в процессе работы сайта меняться не будет, да и даже если будет - добавить/удалить строки в/из файл(а) не представляет труда. Как такие моменты реализовывать максимально правильно? Как поступаете конкретно вы?

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

Есть ли смысл затеваться с хранением блогов/ностей/страниц в файлах, какие недостатки и преимущества. Есть ли смысл разгружать базу перемещая эти данные в файлы?

Меня вразумит дельный совет от человека проектировавшего реальную базу интернет магазина. Да, в идеале я хотел бы готовое решение потому как задача типовая и думаю она давно решена и решение вылизано до идеального, его я и ищу. Моё решение полностью удовлетворяет мои потребности, но кажется мне громоздким, по этому я решил поискать совета профи.

ну конечно... просто супер хранить сериализованое значение массива в базе, а если будет необходимость фильтровать по одному из значений... ммм.. не пойдёт.

http://ru.wikipedia.org/wiki/Первая_нормальная_форма Но всё же приношу извинения, не совсем хорошо понимаю фразу: В первой таблице храните сам товар и в group_id храните массив тип ('1','3','5') где все эти значения - это id свойства товара. Хотя если так то выходит что я с лёгкостью могу выбрать все свойства одного товара, но что если мне нужно получить список товаров из определённой группы и к каждому товару выудить свойства, причём по некоторому условию (только те что удовлетворяют, к примеру или отсортированные по свойству)

в каждом поле таблицы должны храниться атомарные значения. Ваше предложения не отвечает даже NF1

В общем получилась вот такая петрушка. create table products( id int not null primary key, vendor char(128) not null default 'undefined', device char(128) not null default 'undefined', group_id int not null ); create table groups( id int prymary key auto_increment, name char(128) not null default 'undefined' ); create table propertes( group_id int not null name char(128) not null, title char(128) not null default 'undefiden' ); ну и плюс динамически создаваемые таблицы для каждой группы. Не на говорить что это плохо, скажите какие вы видите проблемы и ваши вариации их решения. Буду благодарен.

Да да, для однотипных. но если дынные имеют вид 1:белый:длинный:горячий то не разумно размещать их как 1:белый;1:длинный;1:горячий андерстенд о чём я? к тому же придётся добавлять ключ указывающий тип свойства... или я всё же не понял структуру предложенную выше???

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

получается дублирование значений в таблице свойства товары, если я правильно понял. id товара: id свойства: значение свойства 1:1:10 1:3:15 1:6:синий Можно структуру поподробнее в SQL виде?

да