Как не делать таблицы (если вы очень стараетесь)

[Emelian]

мой путь через проектирование таблиц

Какие таблицы вы имеете в виду? В Экселе, в «1С», в html-страницах или другие?

С точки зрения читателя, любая авторская статья всегда рассматривается с позиции, а что нового или интересного она может ему дать?

Мне, например, интересны html-таблицы. Поэтому, я смотрю на статью с этой точки зрения.

Вот, допустим, я беру html-файл из какого-нибудь онлайн-словаря, скажем, французско-русского. Выбираю достаточно многозначное слово и смотрю, как оно представлено в веб-документе.

Формально, это таблица. Есть ряды, колонки, ячейки. Да и сам искомый блок данных обрамлён тегом «Таблица».

А что на самом деле? Что-то, похожее на «дерево». По крайней мере, извлечь текстовые данные в формате таблицы не получится. Потеряем, либо необходимую структуру, либо связность текста. Ибо эти понятия: «связность» и «структура» данных противоречат друг другу.

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

Другая проблема, структура у словарных статей – «плавающая». Одни иностранные слова – однозначны, другие многозначны, одни определятся своими переводами, другие – формальным описанием, вроде: «определённый артикль женского рода». Одни имеют одну грамматическую форму (существительное, глагол, прилагательное и т.п.), другие – несколько. Одни сопровождаются примерами использования, другие – нет. И т.д. и т.п.

И вся эта «плавающая структура» спокойно себе живет в ячейках html-таблицы, представляя собой, на этом уровне – динамическое дерево.

Я не знаю, в ячейках таблиц, которые вы имеете в виду, бывают динамические данные или у вас данные всегда фиксированного типа? Если вы имеете в виду таблицы баз данных, вроде «1С», то их структурная оптимизация начинается и заканчивается на стороне сервера. А клиенту, как правило, предоставляется только часть данных из одной таблицы либо выборка данных из множества таблиц, по его запросу.

Поэтому, все вопросы, которые вы поднимете, вполне решаются на уровне управления базами данных. Если пользователю что-то не нравится, идем к программисту и говорим: «Ты-ж программист!». Он покраснеет и исправит свои ляпы, наверное.

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

• Создаем список для рядов таблицы.

• Создаем список пар: ключ – значение для каждой ячейки таблицы.

• Ключ – это тег с атрибутами в своем полном виде (в виде строки).

• Значение – эта структура данных для тега ключа.

• Каждый элемент структуры данных значения это либо строка, либо тег со структурой данных.

• К вложенной структуре данных применяем рекурсивно алгоритм по получению пары: Ключ-Значение.

• Структуры данных для ячеек таблицы, являются элементом списка для рядов таблицы.

В итоге, мы рано или поздно сведем все данные к парам: объединенный список всех тегов и конечное (строковое) значение. Применяя закон дистрибутивности из школьной алгебры для 5-го класса, например:

A*(a + B*(b + C*(c + D*d))) = Aa + ABb + ABCc + ABCDd

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

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

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

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

[akardapolov]

В Dimension-UI на широких таблицах

а) по горизонтали переходим сразу на данные по опорному измерению

б) используем транспонирование

Фильтры на таблицах

[Qoragar]

Вариант для "неудобных таблиц" – предоставление (опциональное) пользователю просмотреть данные в виде списка со спойлерами (или даже в таблице, но со второстепенными данными под спойлерами). Главный принцип – всё открывается вниз.

• Плюсы – без регистрации и СМС, всё решается нативными веб-средствами по обработке ваших данных из БД.

• Минусы – потребует более заковыристой работы фронтэндеров и бэкендеров. Но не шибко сильно.

Если у вас массовый рынок – только такой вариант (и безо всяких излишних для этой ЦА "гиковских колдунств", там всё должно быть как раз максимально просто и понятно).