Возникли вопросы по структуре БД

weldp · 13 Апр 2009

Поднимаю старую тему, что бы не плодить новую

Я уже сделал портал в котором:

Таблица описание обьекта(фильм, музыка, книга)
состоит из:

Код:

id имя оригинальное имя описание режисер(он же издатель) год и т.д. 
последнее поле - blob запись с полным описанием обьекта для текущего шаблона.

Так же есть таблица категорий:

Код:

id_категории название_категории

И таблица связей:

Код:

id_категории id_обьекта

Это позволяет:
редактировать любое поле, а изменения ложить в blob запись, а потом тупым:

Код:

SELECT `fullpage`,`id` FROM `media_page`

Мы получаем быстро нужные данные, если еще использовать memcache то думаю вообще круто - маленькие нагрузки...
Но...
Чем больше Я пложу таблиц, для построения связи - надо как минимум 2-е, но обычно 3-и, тем сложнее код и тем сложнее что-либо модифицировать, добавлять....
Вот например сейчас актеры пишутся одной строкой в описание фильма, а Я хочу что бы для каждого актера можно было бы щелкнуть на ссылку и посмотреть описание, можно разрулить ситуацию:
таблица фильмов связанная с таблицей связей, которая связана с таблицей актеров через внешние ключи и через int поля.

Нужно поменять концепцию

Подумал - а почему бы не завести всего 2-а поля:
id_обьекта и blob в котором информация будет хранится:

PHP:

{{name}} данные {{/name}}/::/{{secondname}}данные{{/secondname}}/::/{{year}}данные{{/year}}/::/{{actors}}{{/actors}}.....{{/year}}

Дальше простым
explode /::/ получаем масив, для каждого елемента

Код:

str_replace("{{name}}","<div>",$obj)

или же например елемент массива с актерами:
{{actors}}актер1,актер2,актер3{{/actors}} делим на массив и обрабатываем как нам нужно....
например вставить ссылки:

Код:

<a href="?actor="id">актер1</a>

где id будет хеш....

То есть теперь везде где в базе нельзя было сделать запись одной строкой, а надо было много строк:
данный фильм относится к боевика и драмам

Если Я правильно понял, то Я сэкономлю на записях в БД - сокращу её нагрузку...
Если на imdb 450k фильмов, и каждый из них может иметь от одной до 5-ти категорий, то есть в какой-нить таблице будет записей: 450к*5 = 2.3млн записей макс
+на imdb около 2млн актеров, режиссёров и т.д.
каждому фильму соответствует около 3-15актеров + 1-4 режиссера, то есть в этой таблице связей:
450к*19 =8.5млн записей
Это большие потери в месте и наверное в производительности...

Чем еще может быть плох мой второй подход? (о нагрузке на проц на операциях preg_match / preg_replace Я в курсе

), с другой стороны memcache может сгладить нагрузку...?
И как можно было бы организовать поиск? (Думал прикрутить к sphinx'у, и скорее всего через xml,хотя не понятно как искать...)

ЗЫ:
Может Я тут зря велосипед придумал и умные люди уже давно умеют бороться с нагрузками, гибкостью кода, размером БД, и реализацией детального и обычного поиска

Фанат · 13 Апр 2009

тебе рано еще бороться с нагрузками.

"концепция" твоя - дебилизм.

findnext · 13 Апр 2009

адресочек портала не подкинешь? хочется посмотреть на твои творения

Макс · 13 Апр 2009

Сделай обычную нормализованую структуру БД. Ну разве что счетчики (число просмотров, число комментов и т.п.) можно сразу денормализовать.
Добавь кеширование.
Продумай как будешь мониторить тормоза в системе.
И все. С этим можно уже стартовать и оптимизировать по ходу дела.

weldp · 14 Апр 2009

Автор оригинала: Макс
Сделай обычную нормализованую структуру БД. Ну разве что счетчики (число просмотров, число комментов и т.п.) можно сразу денормализовать.
Добавь кеширование.
Продумай как будешь мониторить тормоза в системе.
И все. С этим можно уже стартовать и оптимизировать по ходу дела.

Блин. это уже есть...
Проблема в следующем:
У Меня актеры в media_page хранятся строкой, теперь что бы де нормализовать надо сделать отдельную таблицу с актерами, отдельную таблицу с связью актер-фильм по внешнему ключу и ЭТО ВСЕ ЗАПРОГРАММИРОВАТЬ, дльше если Я хочу что-то еще добавить - количество таблиц растет, код тоже и Я уже теряюсь в этом.....

Я и спрашиваю, что народ думает по поводу - хранить данные просто в одном поле blob вида:
данные1 /*разделитель*/ данные2 /*разделитель*/
и не строить связи в таблицах через внешние ключи/индексы...

То есть Я тут столкнулся с проблемой места занимаемого связями и сложностью разработкой - если нужно дробить данные...

--
-- База данных: `film2`
--

-- --------------------------------------------------------

--
-- Структура таблицы `category_gid`
--

CREATE TABLE IF NOT EXISTS `category_gid` (
`category_gid` int(255) NOT NULL auto_increment,
`category_name` varchar(255) NOT NULL,
PRIMARY KEY (`category_gid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=7 ;

-- --------------------------------------------------------
INSERT INTO `category_gid` (`category_gid`, `category_name`) VALUES(1, 'Фильмы');
INSERT INTO `category_gid` (`category_gid`, `category_name`) VALUES(2, 'Программы');
--
-- Структура таблицы `category_id`
--

CREATE TABLE IF NOT EXISTS `category_id` (
`category_id` int(255) NOT NULL auto_increment,
`category_gid` int(255) NOT NULL default '1',
`category_name` varchar(255) NOT NULL,
`subgroup_id` int(255) NOT NULL default '0',
PRIMARY KEY (`category_id`),
KEY `category_gid` (`category_gid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------
INSERT INTO `category_id` (`category_id`, `category_gid`, `category_name`, `subgroup_id`) VALUES
(1, 1, 'Боевик', 0);
INSERT INTO `category_id` (`category_id`, `category_gid`, `category_name`, `subgroup_id`) VALUES
(2, 1, 'Драма', 0);

--
-- Структура таблицы `category_uid_id`
--

CREATE TABLE IF NOT EXISTS `category_uid_id` (
`id` int(255) NOT NULL,
`category_id` int(255) NOT NULL,
UNIQUE KEY `id` (`id`,`category_id`),
KEY `category_id_ibfk_1` (`category_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- --------------------------------------------------------
INSERT INTO `category_uid_id` (`id`, `category_id`) VALUES(1, 1);
INSERT INTO `category_uid_id` (`id`, `category_id`) VALUES(2, 1);
--
-- Структура таблицы `login`
--

CREATE TABLE IF NOT EXISTS `login` (
`uid` int(255) NOT NULL auto_increment,
`login` varchar(255) NOT NULL,
`password` varchar(255) NOT NULL,
PRIMARY KEY (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------
-- ТУТ все понятно с даными
--
-- Структура таблицы `media_link`
--

CREATE TABLE IF NOT EXISTS `media_link` (
`link_id` bigint(20) unsigned NOT NULL auto_increment,
`id` int(255) default NULL,
`dcpp` text NOT NULL,
`name` text NOT NULL,
`size` bigint(255) NOT NULL,
`counter` int(255) NOT NULL,
PRIMARY KEY (`link_id`),
KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------
INSERT INTO `media_link` (`link_id`, `id`, `dcpp`, `name`, `size`, `counter`) VALUES(12, 1, 'magnet:?xt=urn:tree:tiger:QAPGFOUWA6L33HDIJAKVE4EWJDQQQP3KJ53W2DI', '13__privedenij.avi', 688, 0);
INSERT INTO `media_link` (`link_id`, `id`, `dcpp`, `name`, `size`, `counter`) VALUES(14, 3, 'magnet:?xt=urn:tree:tiger:4KWFW3MLFKWD45VDV3I37AJPSJ4LLPH2TTQGFMI', '16_kvartalov.avi', 689, 0);

--
-- Структура таблицы `media_page`
--

CREATE TABLE IF NOT EXISTS `media_page` (
`id` int(255) NOT NULL auto_increment,
`name` varchar(255) NOT NULL,
`name2` varchar(255) NOT NULL,
`regiser` varchar(255) NOT NULL,
`actors` longtext NOT NULL,
`review` mediumtext NOT NULL,
`fullpage` longtext NOT NULL,
`abc` varchar(1) NOT NULL,
`abc2` varchar(1) NOT NULL,
`add` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`uid` int(255) NOT NULL,
`count` bigint(255) NOT NULL,
`category_gid` bigint(255) NOT NULL default '1',
`year` varchar(255) character set ucs2 NOT NULL,
`country` varchar(255) NOT NULL,
`quality` varchar(255) NOT NULL,
`en` enum('enable','disable') NOT NULL default 'enable',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Структура таблицы `media_pictures`
--

CREATE TABLE IF NOT EXISTS `media_pictures` (
`pic_id` bigint(255) NOT NULL auto_increment,
`link` varchar(255) NOT NULL,
`id` int(255) default NULL,
PRIMARY KEY (`pic_id`),
KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Дублирующая структура для представления `Sphinx`
--
CREATE TABLE IF NOT EXISTS `Sphinx` (
`id` int(255)
,`category_gid` int(255)
,`cat` varchar(255)
,`category_id` int(255)
,`cat_nam` varchar(255)
,`f_name` varchar(255)
,`f_name2` varchar(255)
,`regiser` varchar(255)
,`actors` longtext
,`review` mediumtext
,`year` varchar(255)
,`country` varchar(255)
);
-- --------------------------------------------------------
INSERT INTO `media_page` (`id`, `name`, `name2`, `regiser`, `actors`, `review`, `fullpage`, `abc`, `abc2`, `add`, `uid`, `count`, `category_gid`, `year`, `country`, `quality`, `en`) VALUES
(1, '13 Привидений', 'Thir13en Ghosts', 'Стив Бек, ', 'Тони Шэлхоуб, Эмбет Дэвидц, Мэттью Лиллард, Шэннон Элизабет, Ра Дигга, ',
'После смерти своего странного дядюшки Сайруса, Артур Критикос унаследовал его не менее странный дом. В этом причудливом здании все стены и пол из стекла, украшенного латинскими заклинаниями. В этом доме автоматические двери живут своей жизнью, открываясь и закрываясь в ритме, недоступном человеческому пониманию. ',
'\n<div id="fullpage"> \n <div id="tabs1"> \n <ul>\n\n <li><a href="#tab1_1"><span>Описание</span></a></li>\n <li><a href="#tab2_1"><span>Постеры</span></a></li>\n <li><a href="#tab3_1"><span>Ссылки для скачивания</span></a></li>\n </ul>\n\n <div id="tab1_1"> \n <img class="mainlogo" src="/image/1/1792430643.jpg" width="117" height="170" alt="media_logo">\n <br>\n <br><p><b>Название</b>: 13 Привидений\n <br><p><b>Оригинальное название</b>: Thir13en Ghosts\n <br><p><b>Год</b>: 2001\n <br><p><b>Жанр</b>: Триллер, Ужасы\n <br><p><b>Режисер</b>: Стив Бек, \n <br><p><b>В ролях</b>: Тони Шэлхоуб, Эмбет Дэвидц, Мэттью Лиллард, Шэннон Элизабет, Ра Дигга, \n <br><p><b>Страна</b>: \n <br><p><b>О фильме</b>: После смерти своего странного дядюшки Сайруса, Артур Критикос унаследовал его не менее странный дом. В этом причудливом здании все стены и пол из стекла, украшенного латинскими заклинаниями. В этом доме автоматические двери живут своей жизнью, открываясь и закрываясь в ритме, недоступном человеческому пониманию. <br>\n </div>\n \n <div id="tab2_1">\n <br><p><b>Название</b>: 13 Привидений\n <br><p><b>Оригинальное название</b>: Thir13en Ghosts \n <br>\n <a href="/image/1/1792430643.jpg" title=" " class="thickbox" rel="gallery-plants_1">\n <img src="/image/1/1792430643.jpg" alt="logo_0" width="117" height="170" />\n </a>\n </div>\n\n <div id="tab3_1">\n <br><p><b>Название</b>: 13 Привидений\n <br><p><b>Оригинальное название</b>: Thir13en Ghosts\n <table>\n <tr>\n <td>\n <a href="magnet:?xt=urn:tree:tiger:QAPGFOUWA6L33HDIJAKVE4EWJDQQQP3KJ53W2DI" >13__privedenij.avi</a>\n </td>\n <td>\n размер:688 Mb\n </td>\n </tr></table>\n </div>\n </div>\n</div>\n ',
'1', 'T', '2008-11-10 03:16:01', 0, 0, 1, '2001', '', '', 'enable');
--
-- Структура для представления `Sphinx`
--
DROP TABLE IF EXISTS `Sphinx`;

CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `film2`.`Sphinx` AS
select `film2`.`category_uid_id`.`id` AS `id`,`film2`.`category_gid`.`category_gid`
AS `category_gid`,`film2`.`category_gid`.`category_name` AS `cat`,`film2`.`category_id`.`category_id` AS `category_id`,
`film2`.`category_id`.`category_name` AS `cat_nam`,`film2`.`media_page`.`name` AS `f_name`,
`film2`.`media_page`.`name2` AS `f_name2`,`film2`.`media_page`.`regiser` AS `regiser`,
`film2`.`media_page`.`actors` AS `actors`,
`film2`.`media_page`.`review` AS `review`,`film2`.`media_page`.`year` AS `year`,
`film2`.`media_page`.`country` AS `country` from (((`film2`.`media_page` join `film2`.`category_gid`) join `film2`.`category_id`) join
`film2`.`category_uid_id`) where ((`film2`.`category_gid`.`category_gid` = `film2`.`category_id`.`category_gid`)
and (`film2`.`category_uid_id`.`category_id` = `film2`.`category_id`.`category_id`)
and (`film2`.`media_page`.`id` = `film2`.`category_uid_id`.`id`));

--
-- Ограничения внешнего ключа сохраненных таблиц
--

--
-- Ограничения внешнего ключа таблицы `category_id`
--
ALTER TABLE `category_id`
ADD CONSTRAINT `category_gid_ibfk_1` FOREIGN KEY (`category_gid`) REFERENCES `category_gid` (`category_gid`)
ON DELETE CASCADE
ON UPDATE CASCADE;

--
-- Ограничения внешнего ключа таблицы `category_uid_id`
--
ALTER TABLE `category_uid_id`
ADD CONSTRAINT `category_id_ibfk_1` FOREIGN KEY (`category_id`) REFERENCES `category_id` (`category_id`)
ON DELETE CASCADE ON UPDATE CASCADE,
ADD CONSTRAINT `category_id_ibfk_2` FOREIGN KEY (`id`) REFERENCES `media_page` (`id`) ON DELETE
CASCADE ON UPDATE CASCADE;

--
-- Ограничения внешнего ключа таблицы `media_link`
--
ALTER TABLE `media_link`
ADD CONSTRAINT `media_link_ibfk_1` FOREIGN KEY (`id`) REFERENCES `media_page` (`id`) ON DELETE
CASCADE ON UPDATE CASCADE;

--
-- Ограничения внешнего ключа таблицы `media_pictures`
--
ALTER TABLE `media_pictures`
ADD CONSTRAINT `media_pictures_ibfk_1` FOREIGN KEY (`id`) REFERENCES `media_page` (`id`)
ON DELETE CASCADE ON UPDATE CASCADE;

dimagolov · 14 Апр 2009

Я и спрашиваю, что народ думает по поводу - хранить данные просто в одном поле blob вида:
данные1 /*разделитель*/ данные2 /*разделитель*/

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

Кроме того:
JOIN используется не так как это делаешь ты, а JOIN tbl2 as tbl_2 ON tbl_2.keyFld = cur_tbl.joinFld
Не делай вложенных запросов, так как они делаются для каждой строки внешнего запроса.

findnext · 14 Апр 2009

weldp
к вышесказанному обрати внимание на размеры ячеек. Тупо ставить varchar 255 - плохая идея, так как в дальнейшем это будет влиять на быстродействие бд

Фанат · 14 Апр 2009

а мне всегда кажалось что для varchar никакой разницы нет

-~{}~ 14.04.09 00:55:

У Меня актеры в media_page хранятся строкой, теперь что бы де нормализовать надо сделать отдельную таблицу с актерами,

это будет наоборот нормализация, дурилка картонная.

vovanium · 14 Апр 2009

капец ну и структура

Интересно типы полей от фонаря ставились?
Зачем для категорий нужны bigint? Причем более того в одном случае у id категорий тип bigint, в других таблицах int.
Для актеров LONGTEXT, это вообще в юмор, т.е. по-твоему даже MEDIUMTEXT с его ограничением в 16 МБ, тебе может не хватить?

И что вообще за записи int(255)?

-~{}~ 14.04.09 00:34:

А еще прикол в таблице utf8, но для поля year сделана кодировка ucs2. Какой там хайлоад, там нужно основы мускуля почитать для начала...

findnext · 14 Апр 2009

если б не было разницы то можно было бы и так писать `name2` varchar(XXXXXXXXXXXXXX) NOT NULL и не беспокоится влезет туда имя или нет.

`id` int(255) NOT NULL auto_increment а это вообще убило, я себе такого числа не могу представить

-~{}~ 14.04.09 01:40:

weldp
вам сюда
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

weldp · 14 Апр 2009

Автор оригинала: dimagolov
нельзя так делать. в первую очередь потому, что это противоречит атомарности данных. для чего нуженв атомарность легко понять если представить ситуацию, когда надо сделать поиск по "данные2"

Я же сказал - поиском будет заниматься sphinx, то есть Мне не нужно делать:

PHP:

SELECT 
		`category_id`.`category_name` AS `uid`,
		`category_gid`.`category_name` AS `group`		
	FROM
		`category_uid_id`,
		`category_id`,
		`category_gid`
	WHERE
		   `category_id`.`category_name`='боевикЪ'
		AND	
		    `category_uid_id`.`category_id`=`category_id`.`category_id`
		AND
		    `category_gid`.`category_gid`=`category_id`.`category_gid`

Где результатом будет `group`=фильмы...

Автор оригинала: dimagolov
Кроме того:
JOIN используется не так как это делаешь ты, а JOIN tbl2 as tbl_2 ON tbl_2.keyFld = cur_tbl.joinFld
Не делай вложенных запросов, так как они делаются для каждой строки внешнего запроса.

Join используется в View для Sphinx'а...это так сказать не относится к делу, так как Я от этого уйду

Автор оригинала: *****
а мне всегда кажалось что для varchar никакой разницы нет допустим тут http://www.intuit.ru/department/database/mysql/4/4.html или тут http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

-~{}~ 14.04.09 00:55:

Вроде ж это не имеет значения для мускуля давненько

Автор оригинала: *****
это будет наоборот нормализация, дурилка картонная.

обшипся

Автор оригинала: vovanium
капец ну и структура Интересно типы полей от фонаря ставились?
Зачем для категорий нужны bigint? Причем более того в одном случае у id категорий тип bigint, в других таблицах int.
Для актеров LONGTEXT, это вообще в юмор, т.е. по-твоему даже MEDIUMTEXT с его ограничением в 16 МБ, тебе может не хватить?
И что вообще за записи int(255)?

Может Я и переборщил с размерами, раньше хотел в этих полях больше 64к хранить информации

Правда это на 100К записей разница дает в 2байта на строку - не существенно...

Ладно это все поэзия и с БД и оптимизацией Я буду разбираться в других форумах, но Я обратился не за этим

Еще раз:
Сейчас есть `id` к которому все привязывается: порядковый номер фильма/книги/музыкальной композиции в базе.

Вот примерно как организована моя база...

Что может быть оптимальней?...
Отказаться от БД, хранить обьекты и т.д. - предложения приветствуются

dimagolov · 14 Апр 2009

Я же сказал - поиском будет заниматься sphinx

weldp, скажи, а как по-твоему, при индексировании sphinx что-то другое и как-то иначе будет читать чем поля БД через SQL запросы? И раз он "будет заниматься" то по-твоему данные надо свалить максимально в кучу чтобы сразу искало "по всему"?

vovanium · 14 Апр 2009

dimagolov

Правда это на 100К записей разница дает в 2байта на строку - не существенно...

Ну так с таким успехом можно для всех полей ставить bigint и longtext... Просто не умеешь планировать структуру, об этом кстати говорит, и то что разные типы полей, для связанных полей...

weldp · 14 Апр 2009

Автор оригинала: dimagolov
weldp, скажи, а как по-твоему, при индексировании sphinx что-то другое и как-то иначе будет читать чем поля БД через SQL запросы? И раз он "будет заниматься" то по-твоему данные надо свалить максимально в кучу чтобы сразу искало "по всему"?

да...можно и так, хотя если все свалить в некий view, то можно указать поля для фильтрации...в док-ии есть это...
ЗЫ:
Я всегда могу поиск передать одному из поисковиков:
google.com "XXX YYYY ZZZZ site:XXX.com"
И не заморачиваться с поиском

vovanium · 14 Апр 2009

И не заморачиваться с поиском

А еще можно передать разработку другому программисту и не заморачиваться

weldp · 14 Апр 2009

Автор оригинала: vovanium
dimagolov

Ну так с таким успехом можно для всех полей ставить bigint и longtext... Просто не умеешь планировать структуру, об этом кстати говорит, и то что разные типы полей, для связанных полей...

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

Например цитата:

тебе рано еще бороться с нагрузками.
"концепция" твоя - дебилизм.

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

Я прошу помощи - как можно это лучше организовать...еще готов выйти из песочницы: php&mysql...

Развиваю свою "дебильную" идею дальше и жду коментов

memcached - это кеш в памяти, который опустошится при отключении питания
memcachedb - это кеш в памяти+на диске, который НЕ опустошится при отключении питания

Оба могут десятки тысяч операций/сек делать что выгоднее чем базы данных

Следующий пример показывает, что в memcacheDB можно хранить обьекты php

PHP:

<?php
//Я работаю тут с memcacheDB
$memcache = new Memcache;
 $memcache->connect('localhost', 21201) or die ("Could not connect");
 $version = $memcache->getVersion();
 echo "Server's version: ".$version." \n";
 $tmp_object = new stdClass;
 $tmp_object->str_attr = 'test string from pavel';
 $tmp_object->int_attr = 123456;
$memcache->set('key1', $tmp_object, false, 10) or die ("Failed to save data at the server");
 $get_result = $memcache->get('key');
 echo "Data from the cache: \n";
 var_dump($get_result);
 echo "get_result->str_attr: ".$get_result->str_attr;
 ?>

Вывод:
Server's version: 1.2.0
Data from the cache:
object(stdClass)#3 (2) {
  ["str_attr"]=>
  string(22) "test string from pavel"
  ["int_attr"]=>
  int(123456)
}

get_result->str_attr: test string from pavel

Так вот Я создаю обьект для каждого типа связи:

PHP:

class obj
{
 public $type='';
 public $actors=array();
 public $regiser=array();
 //и так далее
}

Вставляю в memcachedb эти обьекты, причем ключ у Меня - keyprefix_id:
$memcache->set('keyprefix_id', $tmp_object, false, 10) or die ("Failed to save data at the server")

От базы данных не избавиться(ну пока Я просто не был вынужден этого делать )

В базе храним несколько таблиц:
медианные:
id | название | оригинальное название
Это для того что бы Мы могли по имени найти id, потом добавив keyprefix, сделать
$get_result = $memcache->get('keyprefix_id');

Например:
SELECT `id` WHERE ... ORDER BY ... DESC ...
Дальше
foreach ... {
....$memcache->get('keyprefix_id') //, где keyprefix_id из предыдущего SELECT'а...
}

Вот у Нас: public $actors=array(1,3,9); - такие-то значения...
Мы можем:
$actor1=$memcache->get('actor_1") , $actor2=$memcache->get('actor_3"),$actor3=$memcache->get('actor_9") и получить обьекты actor...

Мы в type кладем версию класса, допустим у нас версия: film1, потом появилась film2 - добавились/изменились/удалились атрибуты в классе, все что нам нужно - case'ом по значению $get_result->type обработать каждый тип по своему усмотрению в контексте задачи...

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

Фанат · 14 Апр 2009

Я же сказал - поиском будет заниматься sphinx

Мне кажется, я уже могу поставить даигноз.
Надо только название хорошее для болезни придумать.

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

Ладно это все поэзия и с БД и оптимизацией Я буду разбираться в других форумах

в этом и заключается разгадка.
Это квинтэссенция ламера системы "не хочу разбираться, как оптимизировать, просто скажите, как быстрее!". Способного, надо сказать, ламера. Умеет ухватиться за пару умных слов - сфинкс, мемкеш. В этих словах он видит панацею от собственной неграмотности. Разумеется, они не помогают. В итоге получается демагогия, закономерная, когда дилетант начинает рассуждать о вещи, в которй он ничего не понимает.

Забавный экспонат.
Но кормить не будем.

-~{}~ 14.04.09 08:23:

Хронофаги
Хронофаг. Словечко это, если не ошибаюсь, придумано Монтерланом. Оно обозначает опасную разновидность людского рода: пожирателей времени. Хронофаг -- это чаще всего человек, у которого нет настоящего дела и который, не зная, на что убить свое время, решает заполнить свой досуг, пожирая ваше. Наглость этой твари невероятна. Он пишет авторам, с которыми не знаком, требуя немедленного ответа; при этом он доходит в своем бессердечии до того, что прилагает к письму почтовую марку, повергая этим благовоспитанного адресата в замешательство; он домогается заведомо ненужной встречи и, если человек, на свою беду, соглашается принять его, докучает ему до тех пор, пока крайнее раздражение хозяина не возьмет верх над учтивостью. Он поведает вам о своей жизни и расспросит о вашей. Счастье, если он ко всему прочему не ведет дневника, куда позднее запишет, что вы, мол, уже не тот, что прежде, куда только делась былая живость, что вы кажетесь угасшим, разговаривать с вами малоинтересно, словом, он сильно разочарован. А будущие биографы, не подозревая, что ваша молчаливость проистекала из вашего негодования, не преминут представить вас в своих описаниях жалким стариком. Не надейтесь умаслить хронофага, бросив ему поглодать частицу вашего времени. Он ненасытен. Подобно тому как пес, которому один из сотрапезников неосмотрительно кинул крылышко цыпленка, непременно возвращается к накормившей его руке и, умильно глядя, протягивает лапу за новой порцией, так и Хронофаг, обнаружив, что перед ним человек мягкий и слабохарактерный, будет безжалостно злоупотреблять этим открытием. Ваша терпимость побудит его явиться снова, писать вам и всячески надоедать. -- У меня много работы, -- неуверенно скажете вы. -- В самом деле? -- спросит Хронофаг. -- Как интересно. И над чем же вы трудитесь? -- Над романом. -- Над романом? Но вся моя жизнь -- роман... И вот его точно пришпорили. Полночь застанет вас на том же месте. Если же он умудрится заманить вас к себе, вы погибли. Вы -- кость, которую он затащил в свою конуру, и, уж будьте уверены, он обгложет вас дочиста. А если он натравит на вас своих приятелей, вас станет пожирать целая свора хронофагов. Эти твари группируются в сообщества и охотно делятся друг с другом добычей
Отсюда мораль: держитесь с хронофагами твердо и беспощадно истребляйте их. Мягкостью и щепетильностью ничего не добьешься. Напротив, эти-то качества и создают микроклимат, в котором хронофаг благоденствует. Он необычайно живуч, и его нужно изничтожать. Мне претит насилие, но в данном случае оно необходимо. Ведь не позволите же вы хищному зверю рвать вас на части, не пытаясь защищаться. А хронофаг подобен хищнику, он отнимает у вас жизнь. Ибо что наша жизнь, как не время. "Где тот человек, который хоть сколько-нибудь ценит время, умеет дорожить каждым днем и понимает, что миг за мигом приближает его к смерти?.. Пока мы откладываем жизнь на завтра, она проходит. Ничто не принадлежит нам в такой степени, как время; оно -- наше. И этим-то единственным и быстротечным достоянием мы позволяем завладевать первому встречному..." Вот, моя дорогая, что писал Сенека своему другу Луцилию две тысячи лет назад, и это доказывает, что хронофаги существуют так же давно, как само человеческое общество. Но главное, да не послужит приступ дурного настроения, в котором вы меня застали, поводом для того, чтобы лишить меня вашего присутствия или скупо отмерять те мгновения, которые вы мне дарите. Женщина, которая нам нравится, никогда не станет хронофагом, она заполняет наше время самым приятным для нас образом. Прощайте.

Андрэ Моруа
Письма незнакомке

weldp · 14 Апр 2009

Автор оригинала: *****
С одной стороны, говорит чудовищные вещи. С другой - вроде бы, не совсем дурак, знает несколько умных слов. Судя по всему, в этих словах, и еще

в этом и заключается разгадка.
Это квинтэссенция ламера системы "не хочу разбираться, как оптимизировать, просто скажите, как быстрее!". Способного, надо сказать, ламера. Умеет ухватиться за пару умных слов - сфинкс, мемкеш. В этих словах он видит панацею от собственной неграмотности. Разумеется, они не помогают. В итоге получается демагогия, закономерная, когда дилетант начинает рассуждать о вещи, в которй он ничего не понимает.

Забавный экспонат.
Но кормить не будем.

-~{}~ 14.04.09 08:23:

Спасибо за ламера...

Ла́мер (от англ. lame — увечный, хромой) — на компьютерном сленге так называют человека, плохо умеющего обращаться с компьютером, неспособного или принципиально не желающего хорошо освоить работу на компьютере....Часто этот термин употребляется для противопоставления понятиям «хакер», «компьютерный гуру». В русском языке вместо слова «ламер» часто употребляют слово «чайник» в значении «неопытный человек».

Я действительно не опытный, вернее свою идею еще на деле не проверял...Но для этого есть опытные люди, которые "видят проблемы"...

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

to Фанат:
В самом начале

Автор оригинала: Макс
Сделай обычную нормализованую структуру БД. Ну разве что счетчики (число просмотров, число комментов и т.п.) можно сразу денормализовать.
Добавь кеширование.
Продумай как будешь мониторить тормоза в системе.
И все. С этим можно уже стартовать и оптимизировать по ходу дела.

Дальше Я:

Автор оригинала: weldp
Блин. это уже есть...

Я понял, что меня просто считают за пустослова, который ни строчки кода не написал...
И я привел старую структур базы данных `film2` до выделения `media_page`.`actors` в отдельную таблицу и постройки связи N-N.

Я даже привел примерную картинку для новой версии:
http://www.save-img.com/pic_b/6814c8e34544ffdf8f1ba3e65afd7312.png
Но Я не понимаю почему все напрыгнули на эту старую версию и начали говорить об оптимизации?
Я озвучил:

Автор оригинала: weldp
Чем больше Я пложу таблиц, для построения связи - надо как минимум 2-е, но обычно 3-и, тем сложнее код и тем сложнее что-либо модифицировать, добавлять....
.....

Нужно поменять концепцию

И что немаловажно:

Автор оригинала: weldp
Может Я тут зря велосипед придумал и умные люди уже давно умеют бороться с нагрузками, гибкостью кода, размером БД, и реализацией детального и обычного поиска

Автор оригинала: weldp
То есть Я тут столкнулся с проблемой места занимаемого связями и сложностью разработкой - если нужно дробить данные...

Автор оригинала: vovanium
капец ну и структура

очень содержательно, Я еще картинку потом прикрепил
http://www.save-img.com/pic_b/6814c8e34544ffdf8f1ba3e65afd7312.png
Но все же

Автор оригинала: vovanium
А еще можно передать разработку другому программисту и не заморачиваться

ЗЫ нужно будет скоро:
200к полных описаний фильмов
500к-1млн описаний людей
500к-1млн описаний книг
300к-1млн описаний музыкальных сборников
2млн фотографий
и бог еще знает что еще....

"не хочу разбираться, как оптимизировать, просто скажите, как быстрее!"

Я не хочу быстрее, Я хочу гибче но в разумных пределах!
Гибче, так как добавить что-то еще: сложную связь - оч. сложно...

vovanium · 14 Апр 2009

очень содержательно

Я тебе написал потом, что имею ввиду, не нужно выдергивать фразы и контекста.

2млн фотографий

Зачем при этом использовать bigint? Ты даже не понимаешь, что используя bigint вместо int, проблема не только в том насколько меньше будет таблицы, но и раза в 2 меньшие индексы, плюс обработка 8 байтных чисел, медленнее чем 4 байтных.

Фанат · 14 Апр 2009

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

Возникли вопросы по структуре БД

Новичок

oncle terrible

Новичок

Старожил PHPClub

Новичок

Новичок

Новичок

oncle terrible

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

oncle terrible

Новичок

Новичок

oncle terrible