Три клиентских адреса в одной таблице или в отдельных таблицах?
Confluent Platform не поддерживается в Windows. Ваш лучший способ запустить его под Docker. Если вы используете Docker, вы можете легко развернуть JDBC-коннектор в Windows.
Но технически kafka-connect-jdbc - это просто плагин JAR для Kafka Connect, который является частью Apache Kafka - так что попробуйте и сообщите, если он работает;)
7 ответов
Если Вы на 100% уверены, что у клиента только когда-либо будет 3 адреса, которые Вы описали затем, это в порядке:
CREATE TABLE Customer
(
ID int not null IDENTITY(1,1) PRIMARY KEY,
Name varchar(60) not null,
customerAddress int not null
CONSTRAINT FK_Address1_AddressID FOREIGN KEY References Address(ID),
deliveryAddress int null
CONSTRAINT FK_Address2_AddressID FOREIGN KEY References Address(ID),
invoiceAddress int null
CONSTRAINT FK_Address3_AddressID FOREIGN KEY References Address(ID),
-- etc
)
CREATE TABLE Address
(
ID int not null IDENTITY(1,1) PRIMARY KEY,
Street varchar(120) not null
-- etc
)
Иначе я смоделировал бы как это:
CREATE TABLE Customer
(
ID int not null IDENTITY(1,1) PRIMARY KEY,
Name varchar(60) not null
-- etc
)
CREATE TABLE Address
(
ID int not null IDENTITY(1,1) PRIMARY KEY,
CustomerID int not null
CONSTRAINT FK_Customer_CustomerID FOREIGN KEY References Customer(ID),
Street varchar(120) not null,
AddressType int not null
-- etc
)
Я пошел бы (как теория баз данных учит) для двух отдельных таблиц: Клиент и Адрес.
Идея поместить три поля в таблицу Customer плоха, как Вы говорите, потому что она нарушила бы правила нормализации (и сбой, когда адреса станут больше чем тремя).
править: также, я разделил запись Таблицы адресов в нескольких полях, один для toponomastic префикса, один для улицы, и т.д. и поместил уникальный ключ на тех. Иначе Вы закончили бы базой данных, полной дубликатов.
Пойдите с 2 таблицами, Клиентом, Адресом.
После того как адреса были созданы в таблице адресов, обычно не позволяют им быть измененными (возможно, определенный инструмент для исправления опечаток). IOW делают идентификатор идемпотента адреса с самим адресом.
Можно теперь сослаться на эти записи таблицы адресов где угодно. Например, то, когда порядок отправлен клиенту идентификатор адреса, на который ссылается таблица Order, может быть тем же как в поле DeliveryAddressID в клиентской таблице.
Если клиент хочет измениться в настоящее время на адресе доставки файла к новому, новая запись адреса создается. Исторические данные доставки незатронуты этим, все же новые заказы автоматически используют новый адрес.
Обратите внимание, что это также полезно при кэшировании объектов Addresss (они неизменны и безопасны в течение длительного срока, кэшируясь), они могут быть распределены и более легко протестированы на равенство (через свойство ID).
Я пошел бы с денормализованным. Это легче.
При нормализации его таблица адресов потребовала бы, чтобы Вы удалили дубликаты, и перессылка записывает от клиентской таблицы. Если у меня были та же доставка и адрес счета, кажется, что это должно связаться с той же записью. Если я изменяюсь один, Вы обязаны:
- Создайте новую запись адреса.
- Повторно свяжите клиентскую запись.
Если я изменяю его назад, необходимо проверить:
- Делает подобную запись адреса, уже существуют.
- Повторно свяжите клиентскую запись.
Это программирование наверху, кажется, устраняет преимущество меньшего количества пространства, которое нормализация, кажется, предлагает. Денормализованное решение, как Вы указанный, обеспечило бы более быстрые запросы и более легкое (мудрое программированием) обслуживание. Это, кажется, решающий фактор для меня.
Нормализованное решение, как указанный выше, позволило бы Вам добавить больше адресов позже. Но необходимо было бы добавить поле для внешнего ключа так или иначе, если Вы не запланировали организацию таблиц без связи от клиента к таблице адресов.
Преимущества нормализованных
- Меньше пространства.
- Копируйте логику, отчасти встроил (хотя, возможно, они не были на самом деле дубликатами?)
- Добавление поддержки новых полей адреса (своего рода).
Преимущества денормализованных
- Более быстрые запросы.
- Меньше программирования.
Я имею это в Корзине Дзэн (и вероятно osCommerce также), в таблице заказов и задался вопросом, почему они пошли тем путем, еще больше поскольку у них есть таблица адресов.
Единственные основания, которые я видел, который допустим, в рекордных целях: даже если клиент изменяет их адреса, информация для заказа не должна изменяться, она отражает данные во время порядка.
Теперь, это немного расточительно, еще больше если тот же клиент делает партию заказов. Возможное решение состоит в том, чтобы сохранить историю адресов и сослаться на них с заказами.
Интересно, должны ли эти неизменные адреса (или изменяемый, если у них еще нет связанного порядка) быть сохранены в регулярной адресной книге или в отдельной, таблице истории, заполнили, только если порядок сделан (избегающие дубликаты, если тот же клиент сохраняет тот же адрес, конечно).
Первый имеет преимущество того, чтобы не иметь две таблицы очень похожих структур и дублированной информации, но мог бы препятствовать действиям (?), когда история растет. Хотя люди редко изменяют эту информацию на практике.
Последний имеет преимущество разделения ролей (каждый неизменен, не другой), редко используемая история.
В целом, если Вы, которых приложение не должно сохранять историей, просто идут для двух разделенных таблиц.
В этом случае помещение каждого поля адреса в различной строке не является нормализацией. Это - просто разделение таблицы. Предположение, что любая схема с большим количеством таблиц "более нормализована", является неправильным.
Скажем, у нас есть эти две альтернативных схемы в базе данных: 1) пользователь: user_id, имя пользователя, пароль
2) пользователь: user_id, password_id пароль: password_id, пароль
(2) "более нормализованы", чем (1)? Нет!
В случае этого OP, настолько же долго как: 1) мы рассматриваем адрес как атомарное значение, 2) приложение только требует тех трех типов адресов.
Затем это так же, как допустимое допустимо для хранения каждого адреса в различном столбце. Второе решение не разлагает адреса на свои компоненты (страна, город, улица, и т.д.). Поэтому это "больше не нормализовано", чем первое!
Мои два цента - это денормализовывающее способ, которым Вы описываете, в порядке, если у Вас есть неопровержимый довод. Иногда та причина может быть столь же простой как высокий уровень уверенности, Вам никогда не будет нужна нормализованная форма. Поскольку Stefan Mai подразумевал, намного легче просто получить и обновить единственную таблицу, если только когда-либо необходимо работать с тремя типами адресов, Вы указали. С другой стороны, если эти три удовлетворяют требование, имеет любую возможность изменения затем, это, вероятно, будет и вначале является лучшим временем для нормализации.