- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Короче, всё, что не Ваше - шлаковое. Нормальная структура у ТС, это только Вам непонятно.
С какой стороны нормальная? Вы читали про древовидные структуры в реляционных базах, в частности, MySQL?
Тут даже от Adjacency List ничего не осталось, всё усложнено в разы. Про Nested Set вообще промолчу.
Рекомендую и вам и ТС почитать, а потом уже блистать в пабликах, троллить, обижаться, да хоть в дудку дуть.
---------- Добавлено 07.10.2016 в 17:29 ----------
Вот только не надо свой личный говнокод преподносить как конфетку.
Говнокод? Пф. Если вы даже не поняли, для чего он предназначен, то, думается, не в говнокоде дело, а в ваших знаниях.
Здравствуй, дерево!😂
Не намерен продолжать эту бесполезную дискуссию.
Дабы не продолжать пустой спор, просто изложу своё видение темы.
Поначалу я вообще не хотел здесь ничего писать, поскольку вопрос был настолько простой, что мне казалось, ответ и без меня быстро отштампуют. Потом всё же выложил алгоритм решения, посчитав, что этого достаточно. Но нет же! Местный учёный народ, по какой-то причине посчитав себя уязвлённым, не только обложил меня словами, но и ещё и накидал мне ху минусов в репутацию. Поэтому отвечаю в полном объёме.
Дана исходная таблица БД:
Такого рода данные встречаются, например, на досках объявлений. Здесь есть рубрики (Rub) и в каждой рубрике категории (Sub). Соответственно Rub_id - родительские элементы, Sub_id - дочерние. Эти идентификаторы обычно выводятся в HTTP-запросах; а для человекопонимания нужны буковки, соответственно в таблице содержатся имена (Rub_name и Sub_name) для рубрик и категорий. При больших объёмах данных имена родительских элементов хранятся в другой таблице, созданной для родительских категорий (чтобы не писать 100500 раз слово "Транспорт", а ссылаться на него по Rub_id=1), но если таблица небольшая, вариант ТС может быть удобным для её чтения человеком, и опять же не надо обращаться к другой таблице через JOIN.
В данном случае для решения поставленной задачи важен не столько запрос к БД, сколько способ его обработки. Нужно сформировать двухмерный массив , отражающий структуру данных. Каждый элемент этого массива должен содержать категории отдельной рубрики. Потом этот массив нужно разобрать на элементы и вывести их в удобном для пользователя виде - например, как список или таблицу. Ниже приведён код, выводящий в браузере список:
Код рабочий, проверил на одном из своих сайтов. Времени на написание всего этого поста ушло больше, чем на написание и проверку кода.
Человек опередил время, правда, скажем, пятью-десятью годами позже.
Стоя, чё.
Не думал, что выкладывая свой код, наткнусь на такое непонимание. Вот и помогай людям.
зачем так остро реагировать? не забывайте что 99% окружающих ненормальны, и все по разному🍿
Такого рода данные встречаются, например, на досках объявлений. Здесь есть рубрики (Rub) и в каждой рубрике категории (Sub). Соответственно Rub_id - родительские элементы, Sub_id - дочерние. Эти идентификаторы обычно выводятся в HTTP-запросах; а для человекопонимания нужны буковки, соответственно в таблице содержатся имена (Rub_name и Sub_name) для рубрик и категорий. При больших объёмах данных имена родительских элементов хранятся в другой таблице, созданной для родительских категорий (чтобы не писать 100500 раз слово "Транспорт", а ссылаться на него по Rub_id=1), но если таблица небольшая, вариант ТС может быть удобным для её чтения человеком, и опять же не надо обращаться к другой таблице через JOIN.
феерично, срочно пишите учебник по созданию разных сайтов, в том числе досок объявлений на php и mysql... не надо себя ограничивать написанием бредотопиков на форумах, вижу ваших знаний вполне хватит на оригинальный инфопродукт ☝
феерично, срочно пишите учебник по созданию разных сайтов
Это было написано для особо "понятливых":) :
Rub_name | Sub_name - это зачем?
И ещё: если жена просит меня вбить 2 гвоздя, чтобы повесить полочку, то я не буду битый час объяснять ей, что
а) лучше всего использовать гвозди не из железа, а из закаленной стали;
б) наибольшей производительности труда при забивании гвоздей можно достичь, используя монтажный пистолет;
в) надо было строить дом не из кирпича, а из монолитного бетона, поскольку в этом случае можно повесить полку гораздо большей грузоподъёмности.
Я просто возьму молоток и вобью 2 гвоздя.
Если есть простой и понятный вопрос, я стараюсь дать простой и понятный ответ, а не пускаться в рассуждения типа "сначала переделай свою базу данных, а потом я дам тебе решение для неё".
зачем так остро реагировать? не забывайте что 99% окружающих ненормальны, и все по разному🍿
По моим понятиям было 95%. Видимо, пора менять свои представления.