Идеи по хранению данных | |
---|---|
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 |
Re: Идеи по хранению данных | |
---|---|
Аспид Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Из задачи, видимо требуется из LIST_MO выбирать отдельные значения?
Иначе не ясны эти телодвижения. Вариант 3, по мне странный, вариант 1 практически равен варианту 2. 1й чуть проще для выборки (написания), 2й для администрирования. пустое) Места на диске не хватит? Ну да, для администрирования, возможно и сложнее, а так, плевать. Ну а массив, все же не из СУБД. Я б поэксперементировал. на 2х вариантах, с разных сторон посмотрел, что удобнее. По скорости (опыт из MS SQL) уверен будет одинаково. |
Re: Идеи по хранению данных | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
Главный вопрос - Как собираешься извлекать?
Если так
то можно так оставить. (правда надо знать что за таблица LIST_MO, ну это проблема сурогатных и естественных ключей) Если так
то тоже можно оставит, навесить только простой индекс на LIST_MO (конечно если размер поля LIST_MO влезает в индекс, если не влезает, то тогда полнотекстовый индекс) Если так
то колхозить свой поиск. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Идеи по хранению данных | |
---|---|
sphinx Автор Сообщений: 31166 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
И отдельные в том числе... Возможна замена части на другую (или удаление) часть (ее как раз можно в одной строке, но далеко не всегда через STRTRAN, а через regexp). При хранении по строкам (с индексом позиции в строке) даже не соображу, как найти такую последовательность без перебора элементов. За время выборки скорее волнуюсь, объем всей базы (даже без архива) увеличится минимум на порядок. По маске. В Постгрессе есть тип поля array, возможна SQL-выборка элементов по индексу. ------------------ "Veni, vidi, vici!"(с) |
Re: Идеи по хранению данных | |
---|---|
Аспид Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Сашь, вряд ли кто ответит верно.
Не ясно что ты хочешь. Есть строка "56-34A-12-56" Ты хочешь ее фрагменты хранить отдельно. Значит каждый из фрагментов отдельная сущность? вопрос правильный, ответ непонятный. Маска это в десктопе. Видимо по фильтру? (where) Т.е. бывает нужно выбрать строки по значению "34A" из сегодняшней строки "56-34A-12-56"? И все же 2й вариант, что бы БД из за этого выросла на ПОРЯДОК!Что то тут не так... Про тип array понял. Но все же не типичная для СУБД штучка. Очень не масштабируемая. Если это принципиально не мешает жизни, лучше придерживаться стандарта SQL 1999, а лучше SQL 92, он все же более реализован в разных СУБД. Тогда переход на другую СУБД, менее затратен. Да и просто, можно подсмотрев конструкцию в одной СУБД, переделать на свою. |
Re: Идеи по хранению данных | |
---|---|
pasha_usue Сообщений: 3647 Откуда: Е-бург Дата регистрации: 06.10.2006 |
Там и поинтереснее конструкции есть. Типа =ANY, например. Но я игрался с массивами в примерно подобной задаче - фигня всё это. Лучше сложить в отдельную таблицу с привязкой к исходной записи. И про порядковый номер не забыть. |
Re: Идеи по хранению данных | |
---|---|
pasha_usue Сообщений: 3647 Откуда: Е-бург Дата регистрации: 06.10.2006 |
Теперь про теорию БД. У тебя в поле лежит составной атрибут. Это нарушает требование к первой нормальной форме. Поэтому нормализованным будет как-раз приведение к первой, либо второй нормальной форме. И ещё немного про массив. Массив это такой костыль первой нормальной формы. Если тебе понадобится ускорить поиск, придётся создавать индексы на каждую колонку массива (если я правильно понял, как ты собираешься искать). |
Re: Идеи по хранению данных | |
---|---|
Ydin Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Реализовать что-то типа
lc1 = "56-34A-12-56" lc2 = '34A' ?'-'+lc2+'-' $ '-'+allt(lc1)+'-' Можно в любой СУБД. У нас на MySql работает. В договорах. Список кодов предприятий, которым данный договор можно показывать. |
Re: Идеи по хранению данных | |
---|---|
pasha_usue Сообщений: 3647 Откуда: Е-бург Дата регистрации: 06.10.2006 |
Саша знает про LIKE, SIMILAR, ~ и т.п. Значит, ему не хватает для конкретных задач, либо не оптимизируется индексами. |
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 |
Re: Идеи по хранению данных | |
---|---|
Владимир Максимов Сообщений: 14095 Откуда: Москва Дата регистрации: 02.09.2000 |
Как уже тут сказали, "ты не с того конца рыбу чистишь" (с) Ты сразу начал с выбранного тобой способа решения, а начать надо с постановки задачи. Какую задачу ты собираешься решить, изменяя структуру данных? А также "стоит ли овчинка выделки?"
1. Сейчас, вот в настоящее время, какие у тебя есть проблемы при существующей структуре базы данных? Что исправить-то надо? 2. Если речь идет о скорости выполнения некой операции (поиск, замена), то насколько часто эта операция выполняется? Т.е. это разовые задачи выполняемые раз в месяц по праздникам или это именно что часто выполняемые операции и их скорость критически важна? 2.1. Можно ли изменить сами бизнес-процессы с тем, чтобы исключить (или существенно уменьшить) те операции, которые выполняются медленно? Например, выполнять поиск по другим критериям или используя другие критерии существенно уменьшить количество записей, где выполняется поиск по маске? Кроме того, если все-таки придешь к выводу, что действительно есть проблема и надо что-то делать, то без понимания логики формирования и использования этого поля что-то посоветовать будет сложно. Ну, например, поиск выполняется по любому фрагменту или заранее известно, что ищем, скажем, второй код, обрамленный дефисами? Надеюсь, понятно, в чем проблема? Мы не в курсе самой постановки задачи. Как следствие, может оказаться так, что предложенные способы решения сами по себе что-то там решают, но конкретно в твоем случае будут не просто бесполезны, но даже вредны. Нормализация - это инструмент. Один из возможных способов решения проблемы. Но далеко не факт, что именно в твоем случае именно его и надо использовать. |
Re: Идеи по хранению данных | |
---|---|
Ydin Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
По маске - это с wildcard?
|
Re: Идеи по хранению данных | |
---|---|
Ydin Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Я по себе знаю, что иногда хочется сделать сложней, чем требуется. Но Like работает быстро и пишется и читается легко и быстро Исправлено 1 раз(а). Последнее : Ydin, 09.09.20 13:39 |
Re: Идеи по хранению данных | |
---|---|
sphinx Автор Сообщений: 31166 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Вектор ответов от разных людей идет на хранение каждого элемента в отдельной строке в формате: ID - идентификатор записи POS - позиция элемента в строке ELEMENT - сам элемент. Тут даже не элемент, а скорее ID из справочника этих элементов. Если большинство людей мыслят одинаково - делаю предположение, что это правильное решение.
Дак да. По маске - это с wildcard! (Хотя в regexp`е скорее '\w') ;) Все именно так. И именно поэтому и начал это обсуждение, что НОРМАЛИЗОВАТЬ хранение составного атрибута. Я описал суть проблемы - нормализация способа хранения составного атрибута. Описал, какие я видел способы хранения и описал, что меня в них смущает. Если описал недостаточно подробно - охотно отвечу на все вопросы для правильной и полной постановки задачи. Такой ответ устроит? ------------------ "Veni, vidi, vici!"(с) |
Re: Идеи по хранению данных | |
---|---|
sphinx Автор Сообщений: 31166 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Цитата: Ну, например, как одним запросом выбрать все неповторяющиеся числовые элементы (могут повторяться с разными буквами, например 47-56Ф-78Т-56-1-14-47Т). Должен получиться результат: 47, 56, 78, 1, 14. Разбирать в цикле с загрузкой в массив - по времени долго работает. Ну и писал, что есть замены/удаления/добавления с разными условиями - например, в этой строке заменить ['56' или '56' + любая буква, кроме "Ф"] на 80. Это можно через регулярные выражения, согласен.
Это часто выполняемые операции, скорость критически важна. Нет, изменить бизнес-процессы никто не даст. Чаще всего известны конкретные элементы, но может быть так: "Вставьте на место второго элемента 90, а элементы, начиная со второго сдвиньте вправо". Вы знаете НА ЧТО нужно менять и знаете ПОЗИЦИЮ. До возможностей регулярных выражений ему далеко. ;) ------------------ "Veni, vidi, vici!"(с) |
Re: Идеи по хранению данных | |
---|---|
Ydin Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Не верю! У нас большие таблицы и в сказки я не верю. Когда еще не видел того, что будет, трудно не преувеличивать! Не надо проходить мимо простого решения. Надо с него начинать! |
Re: Идеи по хранению данных | |
---|---|
Ydin Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
А какие "возможности регулярных выражений"?
Я не буду трахаться, чтобы на запуске формы вместо 10 сек. было 0.5 секунд Поставлю термометр. Но уже работает! Сделай проще, а потом думай. Сначала результат, а потом быстродействие. На быстродействие надо работать не спеша, спокойно. Они потом оценят, что стало быстро! Или в упор не заметят! Или хочешь делать полгода и никто не видит результата. Ты ж за эти дни пока тут тема висит даже не определился, а мог бы уже черновик получить. Исправлено 1 раз(а). Последнее : Ydin, 09.09.20 18:13 |
Re: Идеи по хранению данных | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Если каждый элемент - отдельная сущность, то лучше хранить каждый признак в отдельном поле.
Насчёт выборки "без букв" - можно в UDF-функции это сделать через параметр - "с буквами" или "без букв". Насчёт хранения номера позиции для признака - зачем? В этом нет необходимости. Исправлено 1 раз(а). Последнее : Simple777, 09.09.20 18:18 |
Re: Идеи по хранению данных | |
---|---|
Ydin Сообщений: 7648 Откуда: Киев Дата регистрации: 16.12.2005 |
Simple, уже не помню, что в ДОСе называют сущностью? Какие "с буквами" или "без букв", какие тут UDF-функции? "хранения номера позиции для признака" - согласен, на хрен оно надо. Вообще, по теме IMHO переусложение задачи. Главное, что мы ее не знаем, т.к. знать не дал автор, но хочет, чтобы прониклись таинственностью, типа "ни хера себе"! Исправлено 1 раз(а). Последнее : Ydin, 09.09.20 18:24 |
Re: Идеи по хранению данных | |
---|---|
Simple777 Сообщений: 33855 Дата регистрации: 05.11.2006 |
Понятие "сущность" связано с предметной областью, а не с версией FoxPro. В данном частном случае речь идёт о том, что составной реквизит 11-22-33 является не телефонным номером, а разными признаками чего-то", и что 11 никак не зависит от 22 и 33. Насчет UDF-функции. Речь идёт о том что может быть необходимость собирать и разбирать строку 11-22-33. Если будут использоваться буквы, а не только цифры, то при сборке -разборке можно будет учитывать или не учитывать буквы,и в UDF-функции можно предусмотреть оба варианта. |
© 2000-2024 Fox Club  |