2015-09-15 3 views
1

У меня есть таблица в моей БД для платежей:Несколько дат в одной ячейке DB

ID | Client_ID | Sale Date | Total Payment | Paid | Paid Dates 

И я хочу, чтобы сделать колонки Paid Даты сохранения типа Дата, но если клиент заплатил в несколько этапов, чем должно быть все это даты сохранены. В таблице должно быть столько столбцов, сколько дат плюс первые, но если будет более 20 партий, чем 20 столбцов? Самый простой способ, который я знаю, - связать эти даты в String. И вопрос: Есть ли другой способ сохранения нескольких дат в одной ячейке записи?

+8

Возможно, нормализация будет лучшим решением. –

+1

Не хранить несколько дат в одной ячейке. У вас будут большие проблемы с этим дизайном по дороге. –

ответ

3

Лучший способ сделать это - создать другую таблицу для сохранения дат и привязать ее к исходной таблице с отношением «один ко многим». Пример:

Table1
ID | Client_ID | Дата продажи | Общий платеж | Оплачено

Таблица 2
Таблица1_ID | Paid Date

Это позволяет вам сохранить как можно меньше и меньше дат, поскольку они будут записывать, а не ячейки или конкатенированные значения в одной ячейке.

+0

Это то, чего я не искал :) Так что я также смогу добавить дополнительно сумму платежей в эту вторую таблицу. – Levvy

+0

Да, вы можете добавить сумму и любую другую информацию, которая вам нравится. Затем вы можете удалить «Общий платеж» из первой таблицы и рассчитать его как сумму сумм из второй таблицы. –

3

Вам нужно немного больше дизайна в ваших таблицах. Первая проблема с вашей идеей (несколько дат в одной ячейке) заключается в том, что вам обязательно будет задана сумма, выплаченная по каждой партии. Фактически, как только это слово «рассрочка» вошло в описание проблемы, это признак того, что вам тоже нужно это обозначить.

К счастью, это именно то, что предназначены для реляционных баз данных, и почему существует такая вещь, которая называется database normalization.

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

sales стол:

ID | Client_ID | Дата продажи | Общая оплата

installments стол:

ID | Sale_ID | Дата | Сумма

, чтобы получить все даты и суммы для данной записи продажи:

SELECT Date, Amount FROM Installment WHERE Sale_ID=xxx 

, чтобы получить сумму уже заплатили:

SELECT Sale.ID, Sale.Client_ID, Sale.Sale_Date, -- other 'sale' fields 
    SUM(Installment.Amount) 
FROM Sale 
    LEFT JOIN Installment ON (Installment.Sale_ID=Sale.ID) 
WHERE Sale.XXXXX -- any criteria for selecting the sale record 

, чтобы получить то, что клиент должен вам :

SELECT SUM(Sale.Total_Payment) - SUM(Installment.Amount) 
FROM Sale 
    LEFT JOIN Installment ON (Installment.Sale_ID=Sale.ID) 
WHERE Sale.Client_ID=xxxx 
2

Answer by Javier и Answer by Racil Hilan оба являются правильными.Крамывание нескольких значений в одном поле является неправильным подходом, если вы не являетесь абсолютно 100% вне всякого сомнения уверены, что эти значения будут использоваться только в целом приложением и никогда не будут искать или иным образом получать доступ по значениям подкомпонента.

Именование

Я хотел бы использовать другое имя, кроме Итого Оплата, поскольку это общее в действительности не является еще обязательно оплачена. Возможно Стоимость. Хорошее имя позволяет вашему коду быть самодокументированным.

Советы для SQL имен

Для максимальной переносимости между базами данных, а также, чтобы избежать проблем, названия столбцов со всеми строчными буквами, устранить пробел и символ использовать нижнюю линию (подчеркивание) между словами.

И добавьте задний LOW LINE (underscore). Спецификация SQL явно обещает никогда не использовать конечный знак подчеркивания в любом идентификаторе. Это означает, что вам никогда не придется беспокоиться о столкновении вашего имени с любым из тысяч зарезервированных слов и ключевых слов, используемых различными базами данных. См. this Answer.

So client_id_, date_of_sale_, и cost_.

Диаграмма

Вот ERD diagram, похожий на их предлагаемой конструкции стола. Я использую Postgres data types.

  • Каждый клиент может иметь ноль, один или более записей о продажах.
  • В каждой записи продажи могут быть ноль, один или несколько платежей.
  • Каждая запись продажи должна иметь ровно один назначенный родительский элемент.
  • Каждая запись платежа должна иметь ровно один назначенный родительский элемент.

entity-relationship diagram of 3 tables, client, sale, and payment

Смежные вопросы