Порядок фотографий в галерее

Вид для печати

21.03.2007, 12:03
DELPHIna

Вот возник такой вопрос как же лучше и правильнее сделать?

Есть фотогалерея (в бд табличка типа:
- id
- name(описание фотки)
- ordery (порядок фотки в галерее)
- id_gallery (к какой галерее офтка относится)

у меня сделано так: что все фотки нумеруются хоть от 1...до N, хоть все вначале имееют номер N....
а потом User меняеет как ему надо , кому 1,2,3.... и фотки выводятся в галерее как ему угодно

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

вообщем нужно как то их более уникально что ли по порядку ставить.

Слышала что нужно как то уникально задавать номер(ordery) в пределах галереи, но при удалении фотки сдвигаться же будут все номера??? А может ещё как???

Посоветуйте что нибудь? Может есть уже готовый палгоритм решения...или кто то сам что то делал???

Очень нуждаюсь в совете, примере.
21.03.2007, 12:19
null

Иными словами Вам нужен список [Only registered and activated users can see links. Click Here To Register...]
Храните в записи о фотке номера предыдущей и следующей фоток (если список нужен двунаправленный: т. е. по одной записи Вам надо искать как предыдущую так и следующую), только предыдущей или только следующей (если однонаправленный: тут выбор зависит от алгоритма но вобщем пофиг ссылку на кого хранить) Ну и для каждой коллекции придется хранить как минимум голову списка. Т. е. в итоге Вы поимеете две таблицы: таблицу коллекций, хранящую номера голов списков, названия колеекций и проч., и таблицу фоток, хранящую сведения о фотках и, для каждой фотки, ссылку на соседа. Концевые фотки одну из сцылок (или единственную, в случае с однонаправленным списком) имеют в NULL.
Все просто.

ps: по большому счету пофиг какой одно или двунаправленный список Вы используете. Или, например циклический (ноги ссылаются на голову). Это скорее вопрос удобства, сокращения размеров БД, поиска в БД или времени работы скрипта.
21.03.2007, 12:55
DELPHIna

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

кстати мне фотки что каждый раз нумеровать? т.е. в галереи уже есть куча фоток.... но параметр ordery уних не по порядку....не от 1....N
мне его пронумеровать ещё надо, и каждую новую фотку при вставке нумеровать N+1 так ведь???

что то не варит голова сегодня ваще
21.03.2007, 14:47
Aykroyd

null
Вопрос:

А разве нельзя просто нумеровать фотографии, например, через 10... Или 20... ? А потом по этому полю их сортировать при выводе. Если же понадобится вставить что-то "в середину", можно, например, назначить номер 16. Конечно, не совсем универсальный способ. ))

(я вполне могу заблуждаться, не особо силен в БД, прошу отнестись с пониманием и разъяснить [Only registered and activated users can see links. Click Here To Register...] )
21.03.2007, 16:24
DELPHIna

Aykroyd, а если кончаться...после многолетних перемешевыний местами.... эти цифры между...10,20 ...что тогда???
нет...так точно нельзя...

я как то придумала уже....но точно не оптимально

вообщем если фотки идут так:
1,2,3,4,5,6

и я хочу вставить фотку в позицию 3 ...то я сделала так...что начиная от позиции 4 все смещаются на 1 значение(ordery+1) в конец и сортируются от 4,5,6,7 , не на позицию смещаются а по порядку

заморочка только в том чтобы вставить что то последним тут надо просто похитрее менять местами ...ой, чувствую не мой сегодня день...в принципе работает...но как то точно не оптимально.... приходиться пересортировывать пол таблицы...вернее начиная с позиции куда вставляю(или что меняю местами)....если с 1...то вся таблица, если 20 элемента...то с 20 по N..... точно фигня какая то......

а списками динамическими.....как то навороченно кажется
21.03.2007, 16:40
Aykroyd

Цитата:

Aykroyd, а если кончаться...после многолетних перемешевыний местами.... эти цифры между...10,20 ...что тогда???
нет...так точно нельзя...

Я делал поправку, что предлагаемый мной способ не является универсальным.
21.03.2007, 19:28
null

Aykroyd, вот из-за таких как ты все зло в мире и происходит ... :crazy: [Only registered and activated users can see links. Click Here To Register...] "просто нумеровать"... ты когда-нибудь писал на младших версиях бейсика? никогда строки перенумеровывать не приходилось?.. [Only registered and activated users can see links. Click Here To Register...] :crazy:
DELPHIna, решение со списком вовсе не сложное. это только так кажется. Фукнции для работы со списком элементарные — это же учебное задание дают детишкам чуть не в школе. Этот список ничем от того не отличается. То, что делаете вы на больших коллекциях фоток неоправданно нагружает сервер БД. Если можно писать красиво почему бы не писать красиво [Only registered and activated users can see links. Click Here To Register...]

Я бы сделал так
Таблицы имеют следующий вид
gallery
id // идентификатор, первичный ключ, unsigned tinyint (255 галерей хватит)
title // имя, varchar(50)
description // описание галереи, tinytext или varchar(255) (в зависимости от того что для вас первично — быстродействие или размеры базы; 255 символов для описания имхо вполне достаточно)
head // ссылка на голову списка — id первой фотки из списка в таблице photo

photo
id // идентификатор, первичный ключ, unsigned smallint (65000 фоток в галерее достаточно?)
name // название фотки, varchar(50)
description // описание фотки, tinytext или varchar(255)
prevouse // сцылко на предыдущий элемент (id предыдущего элемента; у головы NULL)
next // сцылко на следующий элемент списка (id следующего элемента; у хвоста NULL)
gallery // идентификатор записи в таблице gallery - это не обязательно, но просто для удобства работы с галереей в целом.

Интерфейс к галерее надо писать так, чтобы можно было просматривать все фотки с фильтрами по любому из полей (кроме id, prevouse и next конечно) — здесь это делается элементарно. извлекать фотки галереи в нужном порядке (один запрос выбирающий все фотки галереи, а затем обработка результата; но, при отсутствии поля gallery можно и серией запросов), создавать галереи (легко и просто — новая запись в gallery), добавлять и удалять фотоки в/из галереи, их сортировка там (тоже просто — элементарные функции работы со списком).

PS: Никакое поле ordery Вам вообще не нужно. оставте его в покое до тех пор, пока не станет понятно, что ваш новый код работает и его, это поле, можно удалить.
21.03.2007, 20:02
Aykroyd

Цитата:

Originally posted by null@Mar 21 2007, 19:28
ты когда-нибудь писал на младших версиях бейсика? никогда строки перенумеровывать не приходилось?..* [Only registered and activated users can see links. Click Here To Register...]* :crazy:
<div align='right'>[Only registered and activated users can see links. Click Here To Register...]

[/quote]
Приходилось. Начинал со встроенного Бейсика на ZX Spectrum в 1990-ом году. Потом был GWBasic на IBM PC/XT, потом Turbo Basic и QBasic на первых эйтишках...

Цитата:

Originally posted by null@Mar 21 2007, 19:28
Aykroyd, вот из-за таких как ты все зло в мире и происходит ...* :crazy:* [Only registered and activated users can see links. Click Here To Register...] "просто нумеровать"...
<div align='right'>[Only registered and activated users can see links. Click Here To Register...]

[/quote]
Я видел, что было до корректировки твоего сообщения. Боюсь, что в следующий раз не успеешь вовремя очередной свой пост откорректировать... ))

Ведь попросил объяснить по-человечески и специально откомментил: "я вполне могу заблуждаться, не особо силен в БД, прошу отнестись с пониманием и разъяснить". Ан нет. В ответ – 90% эмоций и LOL... Грустно. Что ж, возьму на заметку...
21.03.2007, 20:02
Scorched.dn.ua

DELPHIna, идея в принципе правильная, я только не очень понял что ты там сортируешь )) при добавлении фотографии под номером N в базу выполняем следующие запросики

Код:

UPDATE t SET ordery=ordery+1 WHERE ordery>=N INSERT INTO t ( id , name , ordery , ... ) VALUES ( ... , ... , N , ... )

т.е. буквально в две строчки подвигаем элементы и вставляем в середину новую фотку средствами SQL.

null
твой вариант даже в чисто алгоритмическом плане не даёт ни какого выигрыша, а на практике приведет к серьезному снижению скорости работы и неоправданному усложнению и увеличению кода. если интересно могу объяснить подробнее

на Айкройда не наезжай -- он старается помочь ))))))))))
22.03.2007, 00:46
null

Scorched.dn.ua, за этими двумя строчками crhsnf напряженная работа MySQL.
Где там усложнение кода и снижение скорости работы? Объясняй [Only registered and activated users can see links. Click Here To Register...]

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

$result = mysql_query("SELECT * FROM photo WHERE id=$id");
$current = mysql_fetch_array($result);
$result = mysql_query("INSERT INTO photos ( title, description, prevouse, next, gallery ) VALUES ( $title, $description, $id", ".$current['next'].", ".$current['gallery'] );
$result = mysql_query("UPDATE photo SET next=LAST_INSERT_ID() WHERE id=$id");
$result = mysql_query("UPDATE photo SET prevouse=LAST_INSERT_ID() WHERE id=".$current['next'];
22.03.2007, 09:59
Korn

null
вместо двух полей prevouse и next, гораздо проще добавить одно order
в чем выигрыш ты объяснил на уровне
"Выигрыш в том что нет нумерации, в том что нет нумерации" и про какойто бейсик.

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

а вот чтоб добавить новую запись твои методом
нужно вычислить последнюю запись, добавить новую запись, потом получить id новой записи, и изменить старую последнюю запись.

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

$result = mysql_query("SELECT * FROM photo WHERE id=$id");
$current = mysql_fetch_array($result);
$result = mysql_query("INSERT INTO photos ( title, description, prevouse, next, gallery ) VALUES ( $title, $description, $id", ".$current['next'].", ".$current['gallery'] );
$result = mysql_query("UPDATE photo SET next=LAST_INSERT_ID() WHERE id=$id");
$result = mysql_query("UPDATE photo SET prevouse=LAST_INSERT_ID() WHERE id=".$current['next'];

во много раз сложнее чем
$result = mysql_query("INSERT INTO photos ( title, description, order, gallery ) VALUES ( $title, $description, time(), ".$current['gallery'] );
22.03.2007, 11:08
Scorched.dn.ua

_Korn в принципе понял, постараюсь чуть детальнее объяснить почему так делать не стоит.

Алгоритмическая сторона

1. Возьмем готовую таблицу, организованную описанным тобой образом, состоящую к примеру из 100 записей. И тут юзер хочет вставить фотографию например под номером 55. Если ты при этом не используешь "нумерацию", твоему скрипту придется вначале вычислять куда её конкретно вставлять -- т.е. по сути пробегать с 1го элемента, до 55го (ну или с конца - неважно), выполняя для каждого по 1 запросу -- в чем же в итоге оптимизация?? вы при своей вставке выполнили N запросов возвращающих по 1 строчке, а я 1 запрос, изменяющий N строк.

2. Ты можешь предложить вариант: "А я возьму, действительно довалю order к своему динамическому связанному списку, и организую дин. структуру vector". Кстати напомню, что именно vector ускоряет вставку в середину, но никак не обычный list. Но даже используя такую структуру, вам все равно при добавлении нового элемента придется изменять счетчики для всех тех, которые идут после него

Практическая сторона

1. А теперь давай не будем забывать, что у нас тут не массивы с указателями, а всего лишь таблица из БД. И один запрос работающий с сонтей строк отработает на порядок быстрее, чем сто запросов, каждый из которых работает с одной строкой. Только что касается моего запроса, то mysql специально оптимизирован именно для подобных простых запросов, пробегающих разок по всей таблице. А вот поиск 1й записи в таблице с данным индексом, её придется именно искать, т.е. перебирать несколько записей, для каждого такого запроса

2. А теперь тривиальная задача вывода всех фоток, которая происходит намного чаще, чем вставка фотки )) Для того чтобы вывести поочередно фотки, вместо одного "большого" запроса "select from.. order by..." тебе придется опять же выполнять кучу "маленьких" -- по одному для каждого элемента. Еще раз повторюсь "большой" будет выполняться лишь ненамного дольше, чем "маленький".

Вывод: БД предоставляет нам кучу возможностей, надо которыми разработчики парились годами, оптимизируя их, давая возможность конечному программеру просто использовать их не заморачиваясь с придумыванием своих способов хранения и пр., нужно стремиться к простоте
22.03.2007, 11:14
null

_Korn, и фотки, зачем-то, упорядочены по дате и времени добавления. Ну что вы будете потом с этим временем делать? Как изменить их порядок? [Only registered and activated users can see links. Click Here To Register...]
22.03.2007, 11:30
DELPHIna

ндаааа....я точно пошла по пути который описал Korn....а надо наверное по пути null....

ксатти галерея у меня специфичная...нет там сортировки по времени...там времени у фотки вообще нет: выводится всё просто таблицей NxM и всё....и чаще всего нужно не вставлять фотку в середину например, а менять местами те, что уже есть... поменять местами 10 и 5, 18 сделать 1 и так далее.... вставка новой в середину куда реже происходит...

Спасибо...попробую со списком этим....

P.S. а кто то уже делал что то подобное???
22.03.2007, 11:38
null

Цитата:

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]_Korn в принципе понял, постараюсь чуть детальнее объяснить почему так делать не стоит.

_Korn'у я ответил. Либо я не понял, что он имел ввиду, либо то, что он имел ввиду - чушь, либо он сам не понял, что он имел ввиду [Only registered and activated users can see links. Click Here To Register...] Надеюсь, что неправ я [Only registered and activated users can see links. Click Here To Register...]

Цитата:

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. Возьмем готовую таблицу, организованную описанным тобой образом, состоящую к примеру из 100 записей. И тут юзер хочет вставить фотографию например под номером 55. Если ты при этом не используешь "нумерацию", твоему скрипту придется вначале вычислять куда её конкретно вставлять -- т.е. по сути пробегать с 1го элемента, до 55го (ну или с конца - неважно), выполняя для каждого по 1 запросу -- в чем же в итоге оптимизация?? вы при своей вставке выполнили N запросов возвращающих по 1 строчке, а я 1 запрос, изменяющий N строк.

Вставлять надо не после, например, "двенадцатого", а после записи с конкретным id. В передать эти id в интерфейс не сложно, не так ли? Тогда нужно четыре запроса изменяюшие две, и добавляющие одну строку, как я и написал.

Цитата:

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]2. Ты можешь предложить вариант: "А я возьму, действительно довалю order к своему динамическому связанному списку, и организую дин. структуру vector". Кстати напомню, что именно vector ускоряет вставку в середину, но никак не обычный list. Но даже используя такую структуру, вам все равно при добавлении нового элемента придется изменять счетчики для всех тех, которые идут после него

Нет, я не буду это предлагать [Only registered and activated users can see links. Click Here To Register...] По указанной причине.
Вектор ускоряет поиск, а не вставку.

Цитата:

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. А теперь давай не будем забывать, что у нас тут не массивы с указателями, а всего лишь таблица из БД. И один запрос работающий с сонтей строк отработает на порядок быстрее, чем сто запросов, каждый из которых работает с одной строкой. Только что касается моего запроса, то mysql специально оптимизирован именно для подобных простых запросов, пробегающих разок по всей таблице. А вот поиск 1й записи в таблице с данным индексом, её придется именно искать, т.е. перебирать несколько записей, для каждого такого запроса

Для того, чтобы ничего не перебирать в бд существуют индексы. Кстати в MySQL для первичных ключей они создаются автоматически. Так что поиск записи по первичному ключу - операция очень быстрая (вектор, ага [Only registered and activated users can see links. Click Here To Register...])
Возможно MySQL действительно оптимизирован под такие запросы. Этого не знал. Где об этом можно прочесть подробнее?
Впрочем если не хочется растить трафик между web и mysql серверами, то можно оформить функции работы со списком в виде хранимых процедур. MySQL 5 это уже умеет.

Цитата:

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]2. А теперь тривиальная задача вывода всех фоток, которая происходит намного чаще, чем вставка фотки )) Для того чтобы вывести поочередно фотки, вместо одного "большого" запроса "select from.. order by..." тебе придется опять же выполнять кучу "маленьких" -- по одному для каждого элемента.* Еще раз повторюсь "большой" будет выполняться лишь ненамного дольше, чем "маленький".

Вот это суровый аргумент [Only registered and activated users can see links. Click Here To Register...] Думаю здесь тоже стоит сделать хранимую процедуру... Хочу проверить. Давай проверим? Сделаем галереи На MySQL > 5 и php5 (ну можно и на 4). Есть время?

Цитата:

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]Вывод: БД предоставляет нам кучу возможностей, надо которыми разработчики парились годами, оптимизируя их, давая возможность конечному программеру просто использовать их не заморачиваясь с придумыванием своих способов хранения и пр., нужно стремиться к простоте

Нужно стремиться к эффективности. Написать 4 строки вместо одной не так уж сложно.

зы: Я тут столкнулся с такой вот программой, где порядок указывается вручную циферкой. Это ужастно... :stinker:
22.03.2007, 11:40
null

DELPHIna, какая у вас бд? MySQL? Какя версия?
22.03.2007, 12:17
DELPHIna

null, MySQL 4.1.10a - это на сервере....а я ещё локально собираю обычно....у ся дома...а потом выкладываю на сервер, дома 4.1.9 а отчего такой вопрос?...заинтересовали [Only registered and activated users can see links. Click Here To Register...]
22.03.2007, 12:21
Korn

Цитата:

Originally posted by null@Mar 22 2007, 10:14
_Korn,* и фотки, зачем-то, упорядочены по дате и времени добавления. Ну что вы будете потом с этим временем делать? Как изменить их порядок?* [Only registered and activated users can see links. Click Here To Register...]
<div align='right'>[Only registered and activated users can see links. Click Here To Register...]

[/quote]
по умолчанию, при добавлении новой фотки она ставится в конец.
затем, при отображении полного списка фотку можно поменять местами с любой, либо вклинить меджу любыми двумя. и сделать с оредрами это гораздо проще чем твоим методом.
22.03.2007, 12:46
null

DELPHIna, MySQL 4 кажется еще не умеет хранить процедуры. Так что выборка списка превратится в многие запросы к базе [Only registered and activated users can see links. Click Here To Register...]
_Korn, ясно. хоршая идея.
DELPHIna, ну черт его знает... Если в ordery хранить время (случайное число), то придется перебором искать нужный элемент при вставке фотки между двумя другими. Это тоже серия запросов. но зато выборка с сортировкой значительно быстрей, чем у списка. А это таки самая частая операция, как ни крути. Так что можно сделать и так, как предлагает дяденька _Korn [Only registered and activated users can see links. Click Here To Register...]

Бывает еще кэширование. Например с помощью могучей функции ob_start(). Такой метод лечит основной недостаток списка — медленную выборку, а вот алгоритму с ordery не поможет никак...
22.03.2007, 12:54
Korn

null
если надо вклинить между двух,
то поулчаем ордеры этих двух (1 запрос), если их разница больше 1 берем среднее значение из этой разницы, и ставим выбранному это значение( + 1запрос ).
если разница равна 1, меняем все ордеры больше первого на order=order+1 ( 1 запрос ), и ставим ордер второго, выбранному ( 1 запрос )

итого 3 запроса макисимум, в очень редком случае. в остальных, два
22.03.2007, 13:07
null

_Korn, как выглядит запрос, возвращающий две соседние по ordery записи?
22.03.2007, 13:28
Korn

null
если вклинивать, то айдишники записей, между которыми вклиниваем извесны

если надо просто найдти две сосоедние
то тут 2 запроса
SELECT id FROM photo WHERE order > $current_order ORDER BY order LIMIT 1 - следующая запись
SELECT id FROM photo WHERE order < $current_order ORDER BY order DESC LIMIT 1 - предыдущая

$current_order это ордер теущей записи
22.03.2007, 13:31
null

Цитата:

Originally posted by _Korn+Mar 22 2007, 13:28-->

Цитата:

null
если вклинивать, то айдишники записей, между которыми вклиниваем извесны

Да. Достаточно и одного.

<!--QuoteBegin-_Korn@Mar 22 2007, 13:28
[b]null
если надо просто найдти две сосоедние
то тут 2 запроса
SELECT id FROM photo WHERE order > $current_order ORDER BY order LIMIT 1* - следующая запись
SELECT id FROM photo WHERE order < $current_order ORDER BY order DESC LIMIT 1 - предыдущая
$current_order это ордер теущей записи

ок. ясно [Only registered and activated users can see links. Click Here To Register...]
DELPHIna, я не прав. Делайте как говорит дядя _Korn. Так будет проще.
22.03.2007, 13:48
DELPHIna

хорошо....я можно сказатьименно так и делала....правда выражалась небось криво....
_Korn - спасибо...за разъяснения...отстояли Вы свой способ решения....и он по мне так проще намного.

P.S. а можно небольшое разъяснение:вот есть галерея фоток:

1 2 3
4 5 6
7 8 9
10 - -

под каждой фоткой у меня выпадающий список с выбором (ordery) от 1 до 10

если я новую вставляю...например на 8 место...то всё понятно: новая становиться 8_ой, а все за ней смещаются и получается так:

1 2 3
4 5 6
7 8 9
10 11 -

то как лучше сделать
если я хочу 6 например сделать 8(ну типа по центру разместить)???

нужно 7 сделать 6, 8 - седьмой(7), а на место 8 поставить шестую(6) ???

или как то по другому?

если так то что же делать с последней в галереи?
и я хочу поменять местами 9 и 10??? куда смещаться 10??? всего то фоток в галерии 10.... мне не нужно чтобы 10 стала 11....

вот как то не понятно чего User хочет на самом деле.... скажите что мне ему сказать то???? или как переделать алгоритм подмены местами фоток чтобы не глючно это было....
22.03.2007, 17:10
Scorched.dn.ua

Цитата:

Вставлять надо не после, например, "двенадцатого", а после записи с конкретным id. В передать эти id в интерфейс не сложно, не так ли? Тогда нужно четыре запроса изменяюшие две, и добавляющие одну строку, как я и написал.

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

_Korn
да. простейшие запросы в духе такого, как я написал выше.

DELPHIna
если у тебя много свободного времени и энтузиазма, то пропробуй сделать как порекомендовал
null -- во всяком случае это хорошая практика ))

Цитата:

Хочу проверить. Давай проверим? Сделаем галереи На MySQL > 5 и php5 (ну можно и на 4). Есть время?

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

Цитата:

но зато выборка с сортировкой значительно быстрей, чем у списка. А это таки самая частая операция, как ни крути. Так что можно сделать и так, как предлагает дяденька _Korn

Вобще это мне очень напомнило случай, когда я в приведенном мной на одном форуме коде (на С++) для проверки числа на четность использовал "if(i%2)...". А один тамошний форумчанин, тоже великий оптимизатор, начал кричать, мол, где тебя такого учили, все знают, что нужно писать "if( !(i & 1) )...". Закончилось тем, что это проверили, и оказалось, мой вариант отработал быстрее -- просто любой нормальный компилятор все эти вещи видит и знает как корректнее оптимизировать. Так и здесь - есть реляционная бд, вот и используйте подходы реляционных бд, которые уже итак максимально отлажены и оптимизированы, а не избретайте свои, а потом думайте как их оптимизировать. Или напишите свою бд с подходящей структурой организации данных )) Вопрос сродни "Таблицы vs дивы"