логические и более конкретные переменные

Question

Пытаясь создать более совершенные и согласованные соглашения, я хотел получить отзывы о следующих параметрах. Сценарии, которые я использую, включают запись, независимо от того, отправлен ли товар по существующему адресу или по новому.

Обе эти установки помогут понять смысл, но есть ли у них дополнительные плюсы и минусы, о которых я не думаю, или соглашения, которые лучше?

    field name: ship_to
       option 1: new_address
       option 2: existing_address

Pro: 
- Allows for new options down the road if needed.
- Easier to grasp what's going on when looking just a the database

Cons: 
- Not easier to grasp in the code - have to remember the options



    field name: ship_to_new_address
       option 1: true
       option 2: false

Pros / Cons - Pretty much the opposite of what I listed above.

Answer 1

Ответ - нет.

Вы упомянули базу данных, которая, как я предполагаю, означает «Менеджер реляционных баз данных».Ваш дизайн не соответствует правилу one-zero-infinity и требует модификации для поддержки другого адреса доставки в наименее удобное время (например, когда клиент кричит).

Правильная структура данных:

1. Заказчик имеет бесконечные заказы
2. Заказ имеет адрес доставки
3. существует бесконечное количество адресов доставки

Где Customer, Order и Ship-To - это отдельные таблицы базы данных.Это известно как Третья нормальная форма и является стандартной практикой по крайней мере до 1970 года.

Если вам нужно отметить, что у заказа есть нестандартный адрес доставки, запишите, чтологический в Ордене.

Answer 2

Что нужно бизнесу?Вы пытаетесь указать, что адрес доставки изменился?Вы пытаетесь провести различие между новым или существующим адресом?

Тогда, почему вас это волнует?Вы должны указать, чтобы сохранить адрес в базе данных, если новый?Вам нужно сообщить о том, сколько человек было отправлено на несуществующий адрес?

Наконец, вы когда-нибудь сможете использовать более двух вариантов (новых, существующих)?укажет правильное направление.Лично я предпочитаю использовать Boolean, если есть только два варианта, и я не вижу необходимости расширяться.Но я много работаю с внешними API, поэтому изменение требует гораздо больше обдумывания, чем вариант, который является только внутренним.Перечисление (которое, как правило, будет храниться в виде «таблицы типов» в базе данных) является достаточно эффективным, разумным и не слишком тяжелым в хранилище, поэтому это неплохой вариант.

Answer 3

Существует третий вариант:

• Поместите адреса в собственную таблицу (вероятно, с колонкой owner, ссылающейся на таблицу пользователей / учетных записей).
• Используйте столбец ship_to, который указывает на таблицу адресов с внешним ключом.

Плюсы:

• Каждый человек может иметь столько адресов, сколько ему нужно (дом, офис, дача, друзья, ...).
• Хорошо нормализовано.

Единственный минус, о котором я могу думать, это то, что вам придется делать больше объединений, но объединения не являются действительно плохой вещью. Вам может понадобиться немного больше проверки работоспособности, чтобы убедиться, что все владельцы выстроены в очередь, но это тоже не проблема.

Answer 4

Все зависит от того, чего вы пытаетесь достичь. Если все, что вам нужно, это знать, отправлен ли товар по новому адресу или нет, тогда логическое значение ОК.

Я думаю, вам нужно подумать, как сделать вашу архитектуру масштабируемой. Как вы сказали в первом «про», вы можете захотеть иметь больше опций, таких как «временный адрес». Если вам нужны более детерминированные переменные, вы всегда можете использовать перечисление.