:: Visual Foxpro, Foxpro for DOS
Идеи по хранению данных
sphinx
Автор

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Коллеги, надеюсь что общими усилиями получится нормализовать структуру данных.
Попробую описать проблему на коленке (если очень надо для наглядности - скину часть базы (а там нет секретности, это надо ЗНАТЬ, что и куда это вставить).

Итак, структура данных (старая, ее до меня создали лет 10 назад.. Поэтому не ко мне вопросы по говно-хранению. Сорри, за мой нежный..

ID = 104067
LIST_MO = 56-34A-12-56

Как лучше хранить нормализованно запись в столбце LIST_MO?

Есть несколько вариантов, я так вижу
1) распарсить строку (это есть) и сохранит все элементы между
разделителем в отдельную таблицу под общим ID.

Плюсы. Можно сделать выборку одним запросом.
Минусы. На Сотни тысяч записей - как-то не считаю это НОРМАЛИЗОВАННЫМ хранением из-за большого объема данных. Это капец, как база рарастется!

2) Хранить элементы в отдельных столбцах.
Плюсы. Элементарно собирается в СКЛ.
Минусы. Максимум столбцов - 30. Все войдет, даже запись из одного элемента. Но теперь напрягает по ширине, которая не всегда используется

3) Под Постгрессом хранить в виде массива.
Плюсы. Короткая запись, нет избыточного резервирования столбцов. Выбирается на Постгрессе одним запросом (работает с массивами). Возможность обратиться к конкретному элементу по индексу.
Минусы. На Оракле 1-в-1 не перенести (или не все знаю)

Если все варианты кривые - предложите свое видение сохранения. Может в каком-то варианте УБЕДИТЕ, а то как-то растерялся..
Нужны идеи и пояснения, почему именно так видите.
Минусы.


------------------
"Veni, vidi, vici!"(с)




Исправлено 1 раз(а). Последнее : sphinx, 06.09.20 01:33
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Аспид

Сообщений: 3475
Откуда: Москва
Дата регистрации: 01.04.2005
Из задачи, видимо требуется из LIST_MO выбирать отдельные значения?
Иначе не ясны эти телодвижения.

Вариант 3, по мне странный, вариант 1 практически равен варианту 2.
1й чуть проще для выборки (написания), 2й для администрирования.
sphinx
Это капец, как база рарастется
пустое) Места на диске не хватит?
sphinx
Но теперь напрягает по ширине, которая не всегда используется
Ну да, для администрирования, возможно и сложнее, а так, плевать.

Ну а массив, все же не из СУБД.
Я б поэксперементировал. на 2х вариантах, с разных сторон посмотрел, что удобнее.
По скорости (опыт из MS SQL) уверен будет одинаково.
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Главный вопрос - Как собираешься извлекать?

Если так

select * from Table
inner/left/ect join TableWithLIST_MO
on Table.LIST_MO_ID = LIST_MO.ID

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

Если так

select * from TableWithLIST_MO
where LIST_MO = '56-34A-12-56' or LIST_MO Like '56-34A-12-56%'

то тоже можно оставит, навесить только простой индекс на LIST_MO (конечно если размер поля LIST_MO влезает в индекс, если не влезает, то тогда полнотекстовый индекс)

Если так

select * from TableWithLIST_MO
where LIST_MO Like '%6-34A-__-56%'

то колхозить свой поиск.


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
sphinx
Автор

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Аспид
Из задачи, видимо требуется из LIST_MO выбирать отдельные значения?
И отдельные в том числе...

Возможна замена части на другую (или удаление) часть (ее как раз можно в одной строке, но далеко не всегда через STRTRAN, а через regexp). При хранении по строкам (с индексом позиции в строке) даже не соображу, как найти такую последовательность без перебора элементов.

Аспид
Места на диске не хватит?
За время выборки скорее волнуюсь, объем всей базы (даже без архива) увеличится минимум на порядок.

PaulWist
Главный вопрос - Как собираешься извлекать?
По маске.

Аспид
Ну а массив, все же не из СУБД.
В Постгрессе есть тип поля array, возможна SQL-выборка элементов по индексу.


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Аспид

Сообщений: 3475
Откуда: Москва
Дата регистрации: 01.04.2005
Сашь, вряд ли кто ответит верно.
Не ясно что ты хочешь.
Есть строка "56-34A-12-56"
Ты хочешь ее фрагменты хранить отдельно.
Значит каждый из фрагментов отдельная сущность?
sphinx
PaulWist
Главный вопрос - Как собираешься извлекать?
По маске.
вопрос правильный, ответ непонятный. Маска это в десктопе. Видимо по фильтру? (where)
Т.е. бывает нужно выбрать строки по значению "34A" из сегодняшней строки "56-34A-12-56"?

И все же 2й вариант, что бы БД из за этого выросла на ПОРЯДОК!Что то тут не так...
Про тип array понял. Но все же не типичная для СУБД штучка. Очень не масштабируемая.
Если это принципиально не мешает жизни, лучше придерживаться стандарта SQL 1999, а лучше SQL 92, он все же более реализован в разных СУБД.
Тогда переход на другую СУБД, менее затратен. Да и просто, можно подсмотрев конструкцию в одной СУБД, переделать на свою.
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
sphinx
Аспид
Ну а массив, все же не из СУБД.
В Постгрессе есть тип поля array, возможна SQL-выборка элементов по индексу.
Там и поинтереснее конструкции есть. Типа =ANY, например. Но я игрался с массивами в примерно подобной задаче - фигня всё это.

Лучше сложить в отдельную таблицу с привязкой к исходной записи. И про порядковый номер не забыть.
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
sphinx
Минусы. На Сотни тысяч записей - как-то не считаю это НОРМАЛИЗОВАННЫМ хранением из-за большого объема данных. Это капец, как база рарастется!
Теперь про теорию БД. У тебя в поле лежит составной атрибут. Это нарушает требование к первой нормальной форме. Поэтому нормализованным будет как-раз приведение к первой, либо второй нормальной форме.

И ещё немного про массив. Массив это такой костыль первой нормальной формы. Если тебе понадобится ускорить поиск, придётся создавать индексы на каждую колонку массива (если я правильно понял, как ты собираешься искать).
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Ydin

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
Реализовать что-то типа
lc1 = "56-34A-12-56"
lc2 = '34A'
?'-'+lc2+'-' $ '-'+allt(lc1)+'-'

Можно в любой СУБД.
У нас на MySql работает.

В договорах. Список кодов предприятий, которым данный договор можно показывать.
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
Ydin
Реализовать что-то типа
lc1 = "56-34A-12-56"
lc2 = '34A'
?'-'+lc2+'-' $ '-'+allt(lc1)+'-'
Саша знает про LIKE, SIMILAR, ~ и т.п. Значит, ему не хватает для конкретных задач, либо не оптимизируется индексами.
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Simple777

Сообщений: 33855
Дата регистрации: 05.11.2006
Оказывается, несколько лет назад пришлось решать нечто подобное.

Надо прояснить следующий момент. Связаны ли как-то между собой значения 56-34A-12-56?

У меня была такая ситуация. Это была иерархия групп признаков. Число признаков было переменным по отдельным записям. Это могло быть и 2 признака всего, и 10. Поскольку предполагался "сужающийся" поиск по признакам, то я остановился на варианте, когда каждый признак хранится в отдельном поле. Также написал 2 UDF-функции, собирающих и разбирающих строку признаков.

Если же 56-34A-12-56 представляет собой набор независимых друг от друга признаков, то не имеет значения, как хранить эту строку. Но вариант с хранением признаков в отдельных полях может оказаться более "гибким", хотя и потребует выделения большого числа резервных полей.



Исправлено 2 раз(а). Последнее : Simple777, 09.09.20 10:01
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Владимир Максимов

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Как уже тут сказали, "ты не с того конца рыбу чистишь" (с) Ты сразу начал с выбранного тобой способа решения, а начать надо с постановки задачи. Какую задачу ты собираешься решить, изменяя структуру данных? А также "стоит ли овчинка выделки?"

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

2. Если речь идет о скорости выполнения некой операции (поиск, замена), то насколько часто эта операция выполняется? Т.е. это разовые задачи выполняемые раз в месяц по праздникам или это именно что часто выполняемые операции и их скорость критически важна?

2.1. Можно ли изменить сами бизнес-процессы с тем, чтобы исключить (или существенно уменьшить) те операции, которые выполняются медленно? Например, выполнять поиск по другим критериям или используя другие критерии существенно уменьшить количество записей, где выполняется поиск по маске?

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

Ну, например, поиск выполняется по любому фрагменту или заранее известно, что ищем, скажем, второй код, обрамленный дефисами?

Надеюсь, понятно, в чем проблема? Мы не в курсе самой постановки задачи. Как следствие, может оказаться так, что предложенные способы решения сами по себе что-то там решают, но конкретно в твоем случае будут не просто бесполезны, но даже вредны.

Нормализация - это инструмент. Один из возможных способов решения проблемы. Но далеко не факт, что именно в твоем случае именно его и надо использовать.
Ratings: 0 negative/3 positive
Re: Идеи по хранению данных
Ydin

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
По маске - это с wildcard?
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Ydin

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
pasha_usue
Ydin
Реализовать что-то типа
lc1 = "56-34A-12-56"
lc2 = '34A'
?'-'+lc2+'-' $ '-'+allt(lc1)+'-'
Саша знает про LIKE, SIMILAR, ~ и т.п. Значит, ему не хватает для конкретных задач, либо не оптимизируется индексами.

Я по себе знаю, что иногда хочется сделать сложней, чем требуется.
sphinx
В Постгрессе есть тип поля array, возможна SQL-выборка элементов по индексу.
Но Like работает быстро и пишется и читается легко и быстро



Исправлено 1 раз(а). Последнее : Ydin, 09.09.20 13:39
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
sphinx
Автор

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Аспид
Сашь, вряд ли кто ответит верно.

Вектор ответов от разных людей идет на хранение каждого элемента в отдельной строке в формате:
ID - идентификатор записи
POS - позиция элемента в строке
ELEMENT - сам элемент. Тут даже не элемент, а скорее ID из справочника этих элементов.

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

Аспид
Ты хочешь ее фрагменты хранить отдельно.
Значит каждый из фрагментов отдельная сущность?

Дак да.

Аспид
Маска это в десктопе.
По маске - это с wildcard! (Хотя в regexp`е скорее '\w') ;)

pasha_usue
тебя в поле лежит составной атрибут. Это нарушает требование к первой нормальной форме. Поэтому нормализованным будет как-раз приведение к первой, либо второй нормальной форме.
Все именно так. И именно поэтому и начал это обсуждение, что НОРМАЛИЗОВАТЬ хранение составного атрибута.

Владимир Максимов
Ты сразу начал с выбранного тобой способа решения, а начать надо с постановки задачи.
Я описал суть проблемы - нормализация способа хранения составного атрибута. Описал, какие я видел способы хранения и описал, что меня в них смущает. Если описал недостаточно подробно - охотно отвечу на все вопросы для правильной и полной постановки задачи. Такой ответ устроит?


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
sphinx
Автор

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Цитата:
1. Сейчас, вот в настоящее время, какие у тебя есть проблемы при существующей структуре базы данных? Что исправить-то надо?

Ну, например, как одним запросом выбрать все неповторяющиеся числовые элементы (могут повторяться с разными буквами, например 47-56Ф-78Т-56-1-14-47Т). Должен получиться результат: 47, 56, 78, 1, 14. Разбирать в цикле с загрузкой в массив - по времени долго работает. Ну и писал, что есть замены/удаления/добавления с разными условиями - например, в этой строке заменить ['56' или '56' + любая буква, кроме "Ф"] на 80. Это можно через регулярные выражения, согласен.

Владимир Максимов
2. Если речь идет о скорости выполнения некой операции (поиск, замена), то насколько часто эта операция выполняется? Т.е. это разовые задачи выполняемые раз в месяц по праздникам или это именно что часто выполняемые операции и их скорость критически важна?

Это часто выполняемые операции, скорость критически важна.


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

Владимир Максимов
Ну, например, поиск выполняется по любому фрагменту или заранее известно, что ищем, скажем, второй код, обрамленный дефисами?
Чаще всего известны конкретные элементы, но может быть так: "Вставьте на место второго элемента 90, а элементы, начиная со второго сдвиньте вправо". Вы знаете НА ЧТО нужно менять и знаете ПОЗИЦИЮ.

Ydin
Но Like работает быстро и пишется и читается легко и быстро
До возможностей регулярных выражений ему далеко. ;)


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Ydin

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
sphinx
Ydin
Но Like работает быстро и пишется и читается легко и быстро
До возможностей регулярных выражений ему далеко.

Не верю!
У нас большие таблицы и в сказки я не верю.
Когда еще не видел того, что будет, трудно не преувеличивать!
Не надо проходить мимо простого решения.
Надо с него начинать!
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Ydin

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
А какие "возможности регулярных выражений"?
Я не буду трахаться, чтобы на запуске формы вместо 10 сек. было 0.5 секунд
Поставлю термометр. Но уже работает!
Сделай проще, а потом думай.
Сначала результат, а потом быстродействие.
На быстродействие надо работать не спеша, спокойно.
Они потом оценят, что стало быстро! Или в упор не заметят!

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



Исправлено 1 раз(а). Последнее : Ydin, 09.09.20 18:13
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Simple777

Сообщений: 33855
Дата регистрации: 05.11.2006
Если каждый элемент - отдельная сущность, то лучше хранить каждый признак в отдельном поле.

Насчёт выборки "без букв" - можно в UDF-функции это сделать через параметр - "с буквами" или "без букв".

Насчёт хранения номера позиции для признака - зачем? В этом нет необходимости.



Исправлено 1 раз(а). Последнее : Simple777, 09.09.20 18:18
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Ydin

Сообщений: 7648
Откуда: Киев
Дата регистрации: 16.12.2005
Simple777
Если каждый элемент - отдельная сущность, то лучше хранить каждый признак в отдельном поле.
Насчёт выборки "без букв" - можно в UDF-функции это сделать через параметр - "с буквами" или "без букв".
Насчёт хранения номера позиции доя признака - зачем? В этом нет необходимости.

Simple, уже не помню, что в ДОСе называют сущностью?
Какие "с буквами" или "без букв", какие тут UDF-функции?
"хранения номера позиции для признака" - согласен, на хрен оно надо.

Вообще, по теме IMHO переусложение задачи. Главное, что мы ее не знаем, т.к. знать не дал автор, но хочет, чтобы прониклись таинственностью,
типа "ни хера себе"!



Исправлено 1 раз(а). Последнее : Ydin, 09.09.20 18:24
Ratings: 0 negative/0 positive
Re: Идеи по хранению данных
Simple777

Сообщений: 33855
Дата регистрации: 05.11.2006
Ydin
что в ДОСе называют сущностью?
Какие "с буквами" или "без букв", какие тут UDF-функции?

Понятие "сущность" связано с предметной областью, а не с версией FoxPro. В данном частном случае речь идёт о том, что составной реквизит 11-22-33 является не телефонным номером, а разными признаками чего-то", и что 11 никак не зависит от 22 и 33.

Насчет UDF-функции. Речь идёт о том что может быть необходимость собирать и разбирать строку 11-22-33. Если будут использоваться буквы, а не только цифры, то при сборке -разборке можно будет учитывать или не учитывать буквы,и в UDF-функции можно предусмотреть оба варианта.
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 33 dafni_2004  (Гостей: 32)

© 2000-2024 Fox Club 
Яндекс.Метрика