Что предпочтительный путь состоит в том, чтобы сохранить пользовательские поля в базе данных SQL?
Мне удалось преобразовать строку в DWORD и обратно с помощью этого кода:
char strAddr[] = "127.0.0.1"
DWORD ip = inet_addr(strAddr); // ip contains 16777343 [0x0100007f in hex]
struct in_addr paddr;
paddr.S_un.S_addr = ip;
char *strAdd2 = inet_ntoa(paddr); // strAdd2 contains the same string as strAdd
Я работаю в проекте обслуживания старого кода MFC, поэтому преобразование устаревших вызовов функций не применимо.
10 ответов
Мне приходилось много раз заниматься этой ситуацией в течение многих лет, и я согласен с вашей первоначальной идеей изменения таблиц БД напрямую и используя динамические SQL для выработки заявлений.
Создание строки USERATTRIBUTE или столбцов ключей / значения звучит в первую очередь привлекательности, но это приводит к эффекту внутреннего платформы , где вы в конечном итоге приходится повторно реализовать внешние ключи, типы данных, ограничения, транзакции, транзакции, транзакции, Валидация, сортировка, группировка, расчеты и др. Внутри ваших RDBMS. Вы также можете просто использовать плоские файлы, а не SQL вообще.
SQL Server предоставляет таблиц INFORMENT_SCHEMA , которые позволяют вам создавать, запросить и модифицировать схемы таблиц во время выполнения. Это имеет полный тип проверки, ограничения, транзакции, расчеты и все, что вам нужно уже встроен, не изобретают его.
Я видел использование идеи твоего друга в пакете коммерческого учета. Таблица была разделена на две части: первая содержала поля, определяемые исключительно системой, вторая содержала поля, такие как USER_STRING1, USER_STRING2, USER_FLOAT1 и т. Д. Таблицы были связаны по значению идентификатора (когда запись вставляется в основную таблицу, запись с таким же идентификатором) вставляется во второй). Каждая таблица, для которой нужны пользовательские поля, была разбита таким образом.
Я был бы склонен хранить измерения в базе данных в виде строки (varchar) с другим столбцом, идентифицирующим тип измерения. Я полагаю, что он будет исходить из пользовательского интерфейса в виде строки, и приведение к любому другому типу данных может привести к повреждению до сохранения пользовательского ввода.
Недостатком является то, что когда вы собираетесь фильтровать наборы результатов по некоторой метрике измерения, вам все равно придется выполнять приведение, но по крайней мере механизм хранения и сохранения не вносит искажения.
Странно, что так много людей придумывают специальные решения для этого, когда для него имеется хорошо документированный образец:
Entity-Attribute-Value (EAV) Model
Двумя альтернативными вариантами являются XML и вложенные наборы. Управление XML проще, но обычно медленное. Для вложенных наборов обычно требуется какое-либо собственное расширение базы данных, чтобы не создавать беспорядок, например типы CLR в SQL Server 2005 +. Они нарушают первую нормальную форму, но тем не менее являются наиболее быстрым решением.
-121--1670492-Я не думаю, что они включены по умолчанию.
Насколько я понимаю, они должны быть явно установлены с использованием устаревших ?/fresh _ при вызове или аналогичных.
-121--3464992-Давайте скажем, что в базе данных вашего друга должны храниться значения данных из нескольких источников, таких как демографические значения, диагностика, вмешательства, фитономические значения, физиологические экзаменационные значения, значения госпитализации и т.д.
Он может также определить выбор, допустим, его база данных пропускает гонку, и персонал подразделения нуждается в гонке пациента. (различные расы более маловероятны, чтобы получить некоторые заболевания), они могут захотеть использовать раскрывающийся список с несколькими вариантами.
Я бы предложил использовать другую таблицу, которая бы имела эти варианты, или просто использовать «Custom_field_choices» таблицу, которая в какой-то момент точно такая же, но с другим названием.
Учитывая, что база данных:
- должен быть гибким
- данные из нескольких таблиц можно добавлять и настраивать
- чтобы сохранить целостность основной структуры базы данных для целей распространения и однородности
- что данные ДОЛЖНЫ иметь предел и аварийные сигналы и предупреждения
- эти данные должны иметь единицы измерения (10 кг или 10 фунтов)?
- что данные могут иметь выбор вариантов
- данные могут иметь различные права (от простого пользователя до администратора)
- эти данные могут потребоваться для создания отчетов без изменения кода (автоматизация)
- что эти данные могут потребоваться для проведения анализа перекрестных ссылок в системе без изменения кода
пользовательская таблица будет моим решением, изменение каждой таблицы в конечном итоге будет слишком рискованным.
Странно, что так много людей придумывают специальные решения для этого, когда есть хорошо документированный шаблон:
Entity-Attribute-Value (EAV) Model
Две альтернативы - XML и вложенные наборы. XML проще в управлении, но, как правило, медленнее. Вложенные наборы обычно требуют некоторых типов проприетарных расширений базы данных, чтобы обойтись без путаницы, как, например, CLR-типы в SQL Server 2005+. Они нарушают первую нормальную форму, но, тем не менее, являются наиболее быстрым решением.
Microsoft Dynamics CRM достигает этого, изменяя конструкцию базы данных каждый раз, когда изменение производится. Противный, я думаю.
Я бы сказал, что лучший вариант будет рассмотреть таблицу атрибута. Несмотря на то, что они часто нахмуриваются, это дает вам необходимую гибкость, и вы всегда можете создавать представления, используя Dynamic SQL, чтобы выключить данные снова. Просто убедитесь, что вы всегда используете левые присоединения и FKS при создании этих представлений, чтобы оптимизатор запросов может сделать свое задание лучше.
Ну, когда мне нужно хранить неизвестный тип в поле базы данных, я обычно хранят его как строку, сериализацию ее по мере необходимости, а также хранить тип данных.
Таким образом, вы можете иметь какие-либо данные, работающие с любым типом базы данных.
Не могу сказать, как лучше, но могу сказать, как Drupal достигает своего рода схемной структуры, используя при этом стандартные СУБД, доступные сегодня.
Общая идея состоит в том, что есть схематическая таблица со списком полей. Каждая строка на самом деле имеет только два столбца, столбец 'table':String и столбец 'column':String. Для каждого из этих столбцов он на самом деле определяет целую таблицу только с идентификатором и фактическими данными для этого столбца.
Хитрость в том, что когда вы работаете с данными, никогда не более одного присоединения к таблице пакета, которая перечисляет все возможные столбцы, так что в конечном итоге вы не теряете столько скорости, как вы могли бы подумать в ином случае. Это также позволит вам расширять не только несколько медицинских компаний, в отличие от custom_ префикса, который вы предлагали.
MySQL очень быстро возвращает данные строк для коротких строк с несколькими столбцами. Таким образом, эта схема заканчивается довольно быстро, позволяя при этом много гибкости.
Что касается поиска, то моим предложением было бы индексирование содержимого страницы вместо содержимого базы данных. Используйте Solr для разбора отрисованных страниц и удерживайте ссылки на реальную страницу вместо того, чтобы пытаться искать по базе данных, используя умный SQL.
Определите две новые таблицы: Custom_Exam_schema и Custom_Exam_data .
Custom_Exam_data имеет столбец Team_id , а также дополнительный столбец для каждого пользовательского атрибута.
Custom_EXAM_SCHEMA будет иметь ряд , чтобы описать, как интерпретировать каждую из колонн таблицы Custom_Exam_data . У него были бы столбцы, такие как имя , , , , Minvalue , MaxValue и т. Д.
Так, например, для создания Пользовательское поле для отслеживания количества пальцев У человека есть, вы бы добавили («FingerCount», «номер», 0, 10) на Custom_Exam_schema , а затем добавьте столбец с именем FingerCount к экзамену таблицы.
Кто-то может сказать, что плохое изменение схемы базы данных во время выполнения, но я утверждаю, что настройка этих пользовательских полей является частью настроек и не произойдет слишком часто. Тем не менее, этот метод позволяет вам обрабатывать изменения в любое время и не рискует возиться со своими основными схемами таблицы.
Я бы хранил эти пользовательские поля в таблице, где каждая запись (DataType, DataValue, DataUnit) будет использовать в одной строке. Таким образом, будет соотношение оретомании от одного образца к данным. Вы также можете создать таблицу для записи всех типов Cutsom, которые вы будете использовать. Например:
create table DataType
(
id int primary key,
name varchar(100) not null unique
description text,
uri varchar(255) //<-- can be used for an ONTOLOGY
)
create table DataRecord
(
id int primary key,
sample_id int not null,//<-- reference to the sample
dataType_id int not null, //<-- references DataType
value varchar(100),//<-- the value as string
unit varchar(50)//<-- g, mg/ml, etc... but it could also be a link to a table describing the units just like DataType
)