Assume A and B are conceptually different entities that have a few similar properties and of course their own specific properties. In database design, should I put those two entities in one big aggregated table or two respectively designed tables.
For instance, I have two types of payment; Online-payment and Manual-payment with following definition,
TABLE [OnlinePayments]
(
[ID] [uniqueidentifier],
[UserID] [uniqueidentifier],
[TrackingCode] [nvarchar](32),
[ReferingCode] [nvarchar](32),
[BankingAccID] [uniqueidentifier],
[Status] [int],
[Amount] [money],
[Comments] [nvarchar](768),
[CreatedAt] [datetime],
[ShopingCartID] [uniqueidentifier],
)
And
TABLE [ManualPayments]
(
[ID] [uniqueidentifier],
[UserID] [uniqueidentifier],
[BankingAccID] [uniqueidentifier],
[BankingOrgID] [uniqueidentifier],
[BranchName] [nvarchar](64),
[BranchCode] [nvarchar](16),
[Amount] [money],
[SlipNumber] [nvarchar](64),
[SlipImage] [image],
[PaidAt] [datetime],
[Comments] [nvarchar](768),
[CreatedAt] [datetime],
[IsApproved] [bit],
[ApprovedByID] [uniqueidentifier],
)
One of my friends told me that creating two distinct tables for such similar entities is not a well design method and they should be put in one single table for the sake of performance and ease of data manipulations.
I’m now wondering what to do? What is the best practice in such a case?
