Владимир Максимов
Есть еще вариант фасетного кодирования. Т.е. сделать дополнительное поле, где на каждый фрагмент выделяется фиксированное количество символов. Ну, например, на каждый элемент ровно 3 символа, причем первые 2 - число, а последний - буква

"47-56Ф-78Т-56-1-14-47Т" -> "47_56Ф78Т56__1_14_47Т"

Смысл в том, что в этой строке однозначно можно определить все фрагменты по номеру позиции в строке и выделить эти фрагменты по SubStr() явно указав с какой позиции по какую читать

Данный вариант не отличается от следующих:
1. Раскидать значения по отдельным столбцам;
2. Сложить все значения в массив (раз есть тип массив в PG).

Это всё варианты технической реализации одного и того же решения.

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

pasha_usue
Данный вариант не отличается от следующих:
1. Раскидать значения по отдельным столбцам;
2. Сложить все значения в массив (раз есть тип массив в PG).

Это всё варианты технической реализации одного и того же решения.

Согласен. Но автор что-то там говорил про ограничение на количество полей. Или он так жаловался, что их слишком много будет (до 30)? Вот - альтернатива. Все в одном поле

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

У меня работа, уверяю, не стоит - пока занимаюсь другими вещами. Хранится пока в ненормализованном виде, но это переделать несложно.

Владимир Максимов
1. Это часто выполняемая операция для одной записи?

Как правило для группы записей.

Владимир Максимов
2. Если речь идет о выборке, т.е. о получении некоего списка, то как сам список-то получается для которого надо получить эти уникальные наборы? Насколько этот список большой?

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

Цитата:

Если все типичные задачи по модификации ставятся для всех записей таблицы без ограничений, то единственный вариант - это нормализация "до упора". Т.е. таблица с 4 полями
1. Ссылка на запись
2. Номер позиции
3. Числовое значение
4. Буквенное значение

Хорошо. На этом и остановимся. Спасибо!





Исправлено 1 раз(а). Последнее : sphinx, 10.09.20 16:09

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

В отдельных полях хранить значения стоит лишь если они "по смыслу" различны. Если они семантически идентичны, т.е. это на самом деле просто список равнозначных элементов (без разницы чем они разделены, и совсем отдельным будет вопрос "внутренней структуры каждого элемента" - т.е. отделять ли "букву от цифр"), то хранить их в виде набора полей a-la I1, I2, I3 ..., I42 не только не полезно, но и вредно.
Списки в классических, наиболее универсальных случаях хранят "вертикально", т.е. в структуре типа (id, [order,] value). Но если используемая СУБД позволяет хранить данные в массиве, или вложенной таблице, или каком json/xml фрагменте - то в принципе этот вариант стоит рассмотреть - взвесив все "за" (прежде всего отсутствие "лишних" сущностей и извлечение всего набора "за раз") и "против" (зачастую весьма неэффективный поиск "внутри" подобной структуры хранения, и так же часто более сложный процесс модификации - по сути он будет сводится к полному переписыванию всего "набора", а не к точечным изменениям элементов).

Извиняюсь за банальность...

Igor Korolyov
Если они семантически идентичны, т.е. это на самом деле просто список равнозначных элементов

ТС сообщил, что "каждый из фрагментов отдельная сущность".

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

Simple777

Igor Korolyov
Если они семантически идентичны, т.е. это на самом деле просто список равнозначных элементов

ТС сообщил, что "каждый из фрагментов отдельная сущность".

Одно другому не мешает. В списке номеров телефонов конкретного индивида тоже совершенно "отдельные сущности", или в перечне полученных дипломов и наград

-



Исправлено 2 раз(а). Последнее : Ydin, 12.09.20 02:07

Igor Korolyov

Simple777

Igor Korolyov
Если они семантически идентичны, т.е. это на самом деле просто список равнозначных элементов

ТС сообщил, что "каждый из фрагментов отдельная сущность".

Одно другому не мешает. В списке номеров телефонов конкретного индивида тоже совершенно "отдельные сущности", или в перечне полученных дипломов и наград

Тут сущность, что называется - как посмотреть. По факту - в разделителях одна и та же сущность. Но к нее свои атрибуты, она находится в справочнике сущностей. Совсем запутал?

Не ломайте копья - я уже понял, что и Паша Кручинин, и Володя Максимов, и Игорь Королев за строковое хранение. Ну и про первую нормальную форму по Базьяну - прекрасно помню. Ну, были сомнения, захотелось послушать, что мастера скажут. Все норм, по строкам.

sphinx
первую нормальную форму
по Базьяну

?Что это за нормальная форма такая, что то упустил?

Аспид

sphinx
первую нормальную форму
по Базьяну

?Что это за нормальная форма такая, что то упустил?

Стандартное определение ПНФ, данное в книге Базьяна. А ты что подумал?

sphinx

Аспид

sphinx
первую нормальную форму
по Базьяну

?Что это за нормальная форма такая, что то упустил?

Стандартное определение ПНФ, данное в книге Базьяна. А ты что подумал?

Ну есть НФ Клода и еще когото, на Б. НФКБ. Но это от 3й НФ.
Ну и подумал , что то упустил)))

Кхм... я б не стал изучать НФ, по фоксовым книжкам. Сегодня, при наличии инета)
И все же 1я НФ, стремится наеврное надо к 3й

sphinx

Igor Korolyov

Simple777

Igor Korolyov
Если они семантически идентичны, т.е. это на самом деле просто список равнозначных элементов

ТС сообщил, что "каждый из фрагментов отдельная сущность".

Одно другому не мешает. В списке номеров телефонов конкретного индивида тоже совершенно "отдельные сущности", или в перечне полученных дипломов и наград

Тут сущность, что называется - как посмотреть. По факту - в разделителях одна и та же сущность. Но к нее свои атрибуты, она находится в справочнике сущностей. Совсем запутал?

Не ломайте копья - я уже понял, что и Паша Кручинин, и Володя Максимов, и Игорь Королев за строковое хранение. Ну и про первую нормальную форму по Базьяну - прекрасно помню. Ну, были сомнения, захотелось послушать, что мастера скажут. Все норм, по строкам.

Неожиданно пришлось опять вернуться к многоуровнему иерархическому кодированию. Вспомнил, что такая тема была на форуме.

Занимался этим лет 7 назад примерно. За это время "много воды утекло".

Сейчас уже вижу, что ранее принятые решения "были не идеальны", хотя и "жалоб не поступало".

В части таблиц я сделал отдельные поля. Это те таблицы, где нужен "сужающийся поиск", то бишь после ввода очередного признака показывать только те записи, которые содержат этот "старший признак". К слову сказать, количество признаков может быть переменным - от 2 до 10. Если итоговый код хранить в одном поле вместе с разделителями признаков, то сделать такой "сужающийся поиск" с последующим просмотром будет довольно хлопотно - придётся делать, так думаю, какие-нибудь временные таблицы для этого. В случае же отдельных полей для каждого признака всё очень "просто и ясно". Также нет необходимости хранить символы-разделители между признаками.

Так что в итоге я бы так сформулировал.

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



Исправлено 2 раз(а). Последнее : Simple777, 06.03.21 11:08

Пока храню в справочнике в трех форматах - обычная строка, массив (значения между разделителями с буквами), массив значений без букв. Паша Кручини говорил про траблы, однака на курсе в IT Cloud улыбнулись и сказали, что за 10ел проблем. И селектом удобно все вытащить по индексу и по значению. Так что тревога ложная, попробую на массиве. (Пока для информации и обычная строка устраивает, а сильно надо будет, найду плюшки вкусные - так легко и к построчному хранению перейти). Но там объем таблицы возрастает на порядок, не думаю, что это хорошее решение.Довод, что "тебе что, места/памяти жалко" - это можно к нашему руководству, они не пошлют, но уверенно пообещают. Только пообещают.