Я не уверен, что понимаю вопрос.У вас есть выбранная схема хранения записей и вам нужно знать, как лучше всего в ней что-то добавить, или вам нужна также схема хранения?Планируете ли вы разбирать XML на столбцы с nText или просто загружать XML-файл, теги и все в столбцы nText?
Вообще говоря, переходите к узкой, глубокой таблице над широкой, мелкой таблицейесли вы ищете производительность.Узкие таблицы обычно требуют меньше индексов для ускорения поиска по наиболее распространенным столбцам, и эти индексы позволяют механизму разбивать поиск на распараллеливаемые порции.Большинство двигателей также достаточно умны, чтобы отдавать предпочтение «дешевым» условиям фильтра над «дорогими»;предложение LIKE, если оно присутствует, почти наверняка будет выполнено последним в составном предложении WHERE, поэтому, если вы можете предоставить любую другую информацию для сужения поиска, особенно по индексированным столбцам, вы можете ускорить общую производительность вашего запроса.
Вы можете рассмотреть (я не могу поверить, что собираюсь рекомендовать это) схему ключевого вопроса-ответа для данных основного элемента (между открывающим и закрывающим тегами каждого элемента).В любом случае, когда даже часть определения схемы стандартизирована, с традиционной статически определенной таблицей будет легче работать практически по всем показателям, но если вы даже не знаете структуру ваших данных, отличную от той, что в XMLтакой подход потребует своего рода отображения между метаданными конкретного файла и таблицей общих полей, и в этом случае ключ-вопрос-ответ объединит их для лучшей производительности запросов.
Независимо от имеющейся у вас информации, которая однозначно идентифицирует конкретную запись (и / или данные, по которым вам нужно очень быстро искать, чтобы сузить наборы результатов недорого), будет ваш ключ, имя элемента - ваш вопрос, а значениеэто твой ответ.Это будет поддерживать очень гибкий стандарт именования данных.Поскольку данные представляют собой XML и, следовательно, соответствующие данные могут храниться как атрибуты элемента (часть открывающего тега), вам могут потребоваться аналогичные, но более простые таблицы для данных атрибутов поиска для ваших тегов, или вы можете нормализовать данные атрибутов в основной таблице.основан на каком-то известном мэшапе.Наличие этих очень узких строк по строкам на столбцы также позволяет очень легко перемещать необнаруженные столбцы в «архивную» таблицу;вам, вероятно, все еще нужно хранить данные на случай, если они захотят начать поиск по столбцу, но если вы в настоящее время не выполняете поиск по столбцу, вы можете получить их из таблицы, на которой вы выполняете тяжелую работу, что приведет кзначительно сократить время запроса.
Если вы ищете приблизительные значения поля CLOB, вы просто не сможете выполнить запрос LIKE.Да, это будет медленно на очень больших текстовых значениях;Единственный способ помочь этому - разделить этот текст таким образом, чтобы не вызывать ложных несоответствий (где LIKE не найдет совпадения за границами разделения), и я не думаю, что вы найдете универсальныйспособ сделать это;вы должны что-то знать о том, что вы храните, например, что оно в абзацах, и совпадение никогда не пересекает границы абзаца.
Когда все сказано и сделано, я думаю, вы найдете это, независимо от того,По размеру данных большинство СУБД SQL работают достаточно хорошо практически на любой интеллектуальной схеме, если ей хватает ресурсов процессора.Поиск по индексу по своей природе является логарифмическим, а не линейным, поэтому хорошая схема индексации поможет механизму значительно разбить пространство поиска.