Related
Apologies if my fundamental understanding of the issue is incorrect. I am not very experienced with SQL and am still learning.
I am attempting to generate a table for a data set and was given this script:
CREATE TABLE [dbo].[lobbying](
[uniqid] [varchar](36) NOT NULL, [registrant_raw] [varchar](110) NULL, [registrant] [varchar](50) NULL, [isfirm] [char](1) NULL,
[client_raw] [varchar](110) NULL, [client] [varchar](50) NULL,
[ultorg] [varchar](50) NULL,
[amount] [float] NULL,
[catcode] [char](5) NULL,
[source] [char] (5) NULL,
[self] [char](1) NULL,
[IncludeNSFS] [char](1) NULL,
[use] [char](1) NULL,
[ind] [char](1) NULL,
[year] [char](4) NULL,
[type] [char](4) NULL,
[typelong] [varchar](50) NULL, [affiliate] [char](1) NULL,
) ON [PRIMARY]
As you can probably tell, it doesn't work. The script was updated in 2015 so that is why I presume the issue to be the version. I tried using SQL Fiddle to figure out what was causing the issue, and found that taking the brackets out helped(which makes sense, as the tutorial I was following did not use any brackets for their tables). However, even with that, I still receive the error
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'use char(1) NULL,
ind char(1) NULL,
year char(4) NULL,
type char(4) NULL,
typelo' at line 10
Does anybody know what the issue is here? Any help would be greatly appreciated. I've poured out about 4 hours into this project so far and have not been able to get past this roadblock.
It is enough to replace the names with brackets with backticks and also remove the brackets around the type nqames
CREATE TABLE lobbying(
`niqid`varchar(36) NOT NULL
, `egistrant_raw`varchar(110) NULL
, `egistrant` varchar(50) NULL
, `isfirm` char(1) NULL,
`client_raw` varchar(110) NULL
, `client` varchar(50) NULL,
`ultorg` varchar(50) NULL,
`amount` float NULL,
`catcode` char(5) NULL,
`source` char(5) NULL,
`self` char(1) NULL,
`IncludeNSFS` char(1) NULL,
`use` char(1) NULL,
`ind` char(1) NULL,
`year` char(4) NULL,
`type` char(4) NULL,
`typelong` varchar(50) NULL
, `affiliate` char(1) NULL
)
✓
db<>fiddle here
I created an application to replace a legacy one that we had for a while, and I need to move the old database records into the new system, but the schemas are not the same. I'm wondering if there is any way to move the old schema into the new, ignoring the fields that don't exist in the new table, and moving fields that have changed to their updated version.
My old schema is Microsoft SQL Server and has the following fields:
[req_id] [int] IDENTITY(1,1) NOT NULL,
[req_user_id] [nvarchar](50) NOT NULL,
[req_subject] [nvarchar](200) NOT NULL,
[req_details] [nvarchar](4000) NOT NULL,
[req_request_date] [date] NOT NULL,
[req_year] [smallint] NOT NULL,
[req_expect_date] [date] NOT NULL,
[leader] [nvarchar](10) NULL,
[member1] [nvarchar](10) NULL,
[member2] [nvarchar](10) NULL,
[member3] [nvarchar](10) NULL,
[member4] [nvarchar](10) NULL,
[member5] [nvarchar](10) NULL,
[member6] [nvarchar](10) NULL,
[status_code] [nvarchar](10) NULL,
[hours_used] [int] NULL,
[completed_date] [date] NULL,
[category_code] [nvarchar](10) NULL,
[staff_comments] [nvarchar](2000) NULL,
[response_Email] [bit] NOT NULL,
[response_Phone] [bit] NOT NULL,
[response_Fax] [bit] NOT NULL,
[response_online_upload] [bit] NOT NULL,
[response_post_mail] [bit] NOT NULL,
[response_file] [bit] NOT NULL,
[response_pickup] [bit] NOT NULL,
My new schema is MySQL and looks like this:
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`userid` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
`subject` varchar(200) COLLATE utf8_unicode_ci NOT NULL,
`details` text COLLATE utf8_unicode_ci NOT NULL,
`eta` date NOT NULL,
`leader` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`member1` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`member2` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`member3` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`member4` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`member5` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`member6` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`status` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
`time_spent` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`date_completed` date DEFAULT NULL,
`category` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`comments` text COLLATE utf8_unicode_ci,
`response_method` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`updated_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
Is there any way to do this and salvage our old records in the new system?
I used the Data Export tool to generate an xlsx file, then used Navicat to import it as a new table to the database, and then used simple inserts statements to move the data to the other table. I was appalled by the response this question got on SO, but I'm glad I found a solution on my own.
I am getting this error
InsertRecord(InsertRow): HResult of -2147217873 (80040e2f)
Error Source: Microsoft OLE DB Provider for SQL Server Error
Description : The INSERT statement conflicted with the CHECK constraint CK_ContactName. The conflict occurred in database EPIC.7.5_GR_SM_ETLTRAINING; table dbo.ContactName.
The Statements
CREATE TABLE [dbo].[ContactName](
[UniqContactName] [dbo].[DM_UNIQID] IDENTITY(65536,1) NOT NULL,
[UniqFixedContactName] [dbo].[DM_UNIQID] NOT NULL,
[UniqEntity] [dbo].[DM_UNIQID] NOT NULL,
[LkPrefix] [dbo].[DM_PREFIX] NOT NULL,
[FullName] [dbo].[DM_NAME] NOT NULL,
[FirstName] [varchar](30) NOT NULL,
[MiddleName] [varchar](16) NOT NULL,
[LastName] [varchar](30) NOT NULL,
[LkSuffix] [dbo].[DM_SUFFIX] NOT NULL,
[DescriptionOf] [dbo].[DM_DESC_050] NOT NULL,
[Title] [dbo].[DM_TITLE] NOT NULL,
[Department] [dbo].[DM_DEPARTMENT] NOT NULL,
[UniqContactAddressMain] [dbo].[DM_UNIQID] NOT NULL,
[UniqContactAddressEmployer] [dbo].[DM_UNIQID] NOT NULL,
[UniqContactNumberMain] [dbo].[DM_UNIQID] NOT NULL,
[UniqContactNumberEmailMain] [dbo].[DM_UNIQID] NOT NULL,
[ContactMethodCode] [char](1) NOT NULL,
[InformalHeading] [varchar](50) NOT NULL,
[FormalHeading] [varchar](50) NOT NULL,
[BirthDate] [dbo].[DM_DATE] NULL,
[GenderCode] [char](1) NOT NULL,
[SSN] [char](9) NOT NULL,
[MaritalStatusCode] [char](1) NOT NULL,
[RelationToInsuredCode] [char](2) NOT NULL,
[LkLanguage] [dbo].[DM_LANGUAGE] NOT NULL,
[Comments] [dbo].[DM_COMMENT] NOT NULL,
[BillingDeliveryCode] [char](1) NOT NULL,
[ServicingDeliveryCode] [char](1) NOT NULL,
[MarketingDeliveryCode] [char](1) NOT NULL,
[CategoryCode] [char](1) NOT NULL,
[EmployerName] [dbo].[DM_NAME] NOT NULL,
[LkOccupation] [dbo].[DM_OCCUPATION] NOT NULL,
[HiredDate] [dbo].[DM_DATE] NULL,
[YearsEmployed] [smallint] NULL,
[YearsPriorEmployer] [smallint] NULL,
[FEIN] [char](9) NOT NULL,
[DUNSNumber] [char](9) NOT NULL,
[CdNAICSCode] [char](6) NOT NULL,
[CdSICCode] [char](8) NOT NULL,
[BusinessTypeCode] [char](2) NOT NULL,
[BusinessTypeOtherDesc] [varchar](50) NOT NULL,
[NumberEmployees] [smallint] NULL,
[NumberMembersManagers] [int] NULL,
[BusinessStartedDate] [datetime] NULL,
[NatureOfBusinessCode] [char](2) NOT NULL,
[NatureOfBusinessOtherDesc] [varchar](50) NOT NULL,
[CreditBureauNameCode] [char](5) NOT NULL,
[CreditBureauNameOtherDesc] [varchar](50) NOT NULL,
[CreditBureauIDNumber] [varchar](30) NOT NULL,
[DriverLicenseNumber] [varchar](25) NOT NULL,
[LicensedState] [char](4) NOT NULL,
[LicensedDate] [datetime] NULL,
[LicensedMADate] [dbo].[DM_DATE] NULL,
[DriverTypeCode] [char](1) NOT NULL,
[GoodStudentCode] [char](1) NOT NULL,
[DriverTrainingCode] [char](1) NOT NULL,
[AccidentPreventionCourseDate] [dbo].[DM_DATE] NULL,
[CommercialExperienceBeganDate] [dbo].[DM_DATE] NULL,
[MatchClientNameOf] [smallint] NOT NULL,
[InsertedByCode] [dbo].[DM_INSERTUPDATEBYCODE] NOT NULL,
[InsertedDate] [dbo].[DM_DATETIME] NOT NULL,
[UpdatedByCode] [dbo].[DM_INSERTUPDATEBYCODE] NOT NULL,
[UpdatedDate] [dbo].[DM_DATETIME] NULL,
[Flags] [dbo].[DM_FLAGS] NOT NULL,
[ts] [datetime] NOT NULL,
[SIN] [char](9) NOT NULL,
[BusinessNumber] [varchar](30) NOT NULL,
[BusinessIDNumber] [varchar](30) NOT NULL,
[IBCCode] [char](6) NOT NULL,
CONSTRAINT [PK_ContactName] PRIMARY KEY NONCLUSTERED ALTER TABLE [dbo].[ContactName]
WITH CHECK ADD CONSTRAINT [CK_ContactName]
CHECK ((
[UniqContactName]=(-1)
AND [UniqEntity]=(-1)
OR [UniqContactName]>(-1)
AND [UniqEntity]>(-1)
))
GO
I have checked contactName db and all the rows from uniqueContactName all have a value above 65000, then for UniqEntity they all are above 65000 as well.
Does anyone have an idea why this would fail?
I have a database that is connected to SQL Server 2008, I am getting an error when printing database : Printing aborted! Error 37000 (Microsoft OLE DB Provider for ODBC Drivers) - [Microsoft] [ODBC SQL Server Driver] [SQL Server] [Incorrect syntax near 'TEMP_TAB_SHEET_U17'.
Details script as below :
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [data].[TEMP_TAB_SHEET_U17](
[TAL] [varchar](30) NULL,
[Phase] [smallint] NOT NULL,
[SHT] [varchar](30) NULL,
[PreferedSYS] [varchar](30) NULL,
[sysdesc] [varchar](100) NULL,
[EquipmentNumber] [varchar](30) NULL,
[TaskNumber] [varchar](30) NULL,
[TaskId] [int] NULL,
[OTdescription] [varchar](50) NULL,
[OTremark] [varchar](50) NULL,
[Estimated_Man_Hours] [float] NULL,
[EquipmentId] [int] NULL,
[EquipmentDescription] [varchar](50) NULL,
[TAA_ID] [int] NULL,
[UserGroup] [varchar](30) NULL,
[MODULE] [varchar](30) NULL,
[ModuleDesc] [varchar](50) NULL,
[SHTTitle1] [varchar](50) NULL,
[SHTTitle2] [varchar](50) NULL,
[SHTTitle3] [varchar](50) NULL,
[SHTTitle4] [varchar](50) NULL,
[SHTDescription] [varchar](50) NULL,
[SHTNbSections] [int] NULL,
[NbMaxTasksPerSheet] [int] NULL,
[S1_PH] [varchar](30) NULL,
[S1_M] [varchar](30) NULL,
[S1_PF] [varchar](30) NULL,
[S2_PH] [varchar](30) NULL,
[S2_M] [varchar](30) NULL,
[S2_PF] [varchar](30) NULL,
[S3_PH] [varchar](30) NULL,
[S3_M] [varchar](30) NULL,
[S3_PF] [varchar](30) NULL,
[SHTFooterTitle1] [varchar](50) NULL,
[SHTFooterTitle2] [varchar](50) NULL,
[SHTFooterTitle3] [varchar](50) NULL,
[SHTFooterTitle4] [varchar](50) NULL,
[SHTFooterTitle5] [varchar](50) NULL,
[SHTFooterTitle6] [varchar](50) NULL,
[SHTFooterTitle7] [varchar](50) NULL,
[SHTFooterTitle8] [varchar](50) NULL,
[SHTFooterTitle9] [varchar](50) NULL,
[SHTFooterTitle10] [varchar](50) NULL,
[SHTFooterTitle11] [varchar](50) NULL,
[SHTFooterTitle12] [varchar](50) NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
ALTER TABLE [data].[TEMP_TAB_SHEET_U17] ADD DEFAULT ((0)) FOR [Phase]
GO
Query completed running with the error :
Msg 2714, Level 16, State 6, Line 2
There is already an object named 'TEMP_TAB_SHEET_U17' in the database.
Msg 1781, Level 16, State 1, Line 2
Column already has a DEFAULT bound to it.
Msg 1750, Level 16, State 0, Line 2
Could not create constraint. See previous errors.
How to solve this problem.
Thank you in advance.
Awan
Have you tried to set the constrain on creation:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [data].[TEMP_TAB_SHEET_U17](
[TAL] [varchar](30) NULL,
[Phase] [smallint] NOT NULL DEFAULT 0,
...
....
GO
SET ANSI_PADDING OFF
GO
I have a budding developer who is very enthusiastic about something he is calling “the matrix”
I am looking for peer insight
In a nutshell this is what we have:
- 1 highly denormalized table with about 120 columns
- Data points range from account, customer, household, relationship, product, employee, etc…
- One index per column: about 120 non-clustered indexes
- About 90% of all space in the database used by indexes today are indexes on this table
- Today about 1.5 million rows with a lot of nulls
- Table loaded with a stored procedure whose core is dynamic SQL
- All Field names are generic and do not describe the data
- A data dictionary type table is used with the dynamic SQL to load any data point to any field
- Field mapping is not static: today column dim_0001 is customer name, but tomorrow maybe something else
- No primary key
- No foreign keys
- No real constraints (For example all fields are nullable)
The argument for the table:
- Makes writing queries simpler because it eliminates the needs to write some join
The intended use:
- An End User Layer and would be a core component of a Universe build in Business Objects
- Post ETL process development
My recommendation will either kill the process where it is today (early development in a test environment) or move it to the next step in test.
Based on the research I have done, my education, and experience I do not support it and want the tables dropped as soon as the one or two processes that depend on these tables have been migrated to another solution.
Script below for your reference (I limited to one index example).
Any insight you can offer (even just a one word opinion) is valuable
-- The Matrix
CREATE TABLE [z005497].[tblMatrix](
[as_of_dt] [datetime] NOT NULL,
[dim_0001] [varchar](100) NULL,
[dim_0002] [varchar](103) NULL,
[dim_0003] [varchar](100) NULL,
[dim_0004] [varchar](100) NULL,
[dim_0005] [varchar](100) NULL,
[dim_0006] [varchar](100) NULL,
[dim_0007] [varchar](100) NULL,
[dim_0008] [varchar](100) NULL,
[dim_0009] [varchar](100) NULL,
[dim_0010] [varchar](100) NULL,
[dim_0011] [varchar](100) NULL,
[dim_0012] [varchar](100) NULL,
[dim_0013] [varchar](100) NULL,
[dim_0014] [varchar](100) NULL,
[dim_0015] [varchar](100) NULL,
[dim_0016] [varchar](100) NULL,
[dim_0017] [varchar](103) NULL,
[dim_0018] [varchar](103) NULL,
[dim_0019] [varchar](103) NULL,
[dim_0020] [varchar](103) NULL,
[dim_0021] [varchar](103) NULL,
[dim_0022] [varchar](103) NULL,
[dim_0023] [varchar](103) NULL,
[dim_0024] [varchar](103) NULL,
[dim_0025] [varchar](103) NULL,
[dim_0026] [varchar](11) NULL,
[dim_0027] [varchar](11) NULL,
[dim_0028] [varchar](11) NULL,
[dim_0029] [varchar](11) NULL,
[dim_0030] [varchar](11) NULL,
[dim_0031] [varchar](11) NULL,
[dim_0032] [varchar](11) NULL,
[dim_0033] [varchar](11) NULL,
[dim_0034] [varchar](11) NULL,
[dim_0035] [varchar](11) NULL,
[dim_0036] [varchar](11) NULL,
[dim_0037] [varchar](11) NULL,
[dim_0038] [varchar](11) NULL,
[dim_0039] [varchar](11) NULL,
[dim_0040] [varchar](11) NULL,
[dim_0041] [varchar](11) NULL,
[dim_0042] [varchar](11) NULL,
[dim_0043] [varchar](11) NULL,
[dim_0044] [varchar](11) NULL,
[dim_0045] [varchar](11) NULL,
[dim_0046] [varchar](11) NULL,
[dim_0047] [varchar](11) NULL,
[dim_0048] [varchar](11) NULL,
[dim_0049] [varchar](11) NULL,
[dim_0050] [varchar](11) NULL,
[dim_0051] [varchar](11) NULL,
[dim_0052] [varchar](11) NULL,
[dim_0053] [varchar](11) NULL,
[dim_0054] [varchar](5) NULL,
[dim_0055] [varchar](5) NULL,
[dim_0056] [varchar](5) NULL,
[dim_0057] [varchar](5) NULL,
[dim_0058] [varchar](5) NULL,
[dim_0059] [varchar](5) NULL,
[dim_0060] [varchar](5) NULL,
[dim_0061] [varchar](5) NULL,
[dim_0062] [varchar](5) NULL,
[dim_0063] [varchar](5) NULL,
[dim_0064] [varchar](5) NULL,
[dim_0065] [varchar](5) NULL,
[dim_0066] [varchar](5) NULL,
[dim_0067] [varchar](5) NULL,
[dim_0068] [varchar](5) NULL,
[dim_0069] [varchar](5) NULL,
[dim_0070] [varchar](5) NULL,
[dim_0071] [varchar](5) NULL,
[dim_0072] [varchar](5) NULL,
[dim_0073] [varchar](5) NULL,
[dim_0074] [varchar](5) NULL,
[dim_0075] [varchar](5) NULL,
[dim_0076] [varchar](5) NULL,
[dim_0077] [varchar](5) NULL,
[dim_0078] [varchar](5) NULL,
[dim_0079] [varchar](5) NULL,
[dim_0080] [varchar](5) NULL,
[dim_0081] [varchar](5) NULL,
[dim_0082] [varchar](5) NULL,
[dim_0083] [varchar](5) NULL,
[dim_0084] [int] NULL,
[dim_0085] [int] NULL,
[dim_0086] [int] NULL,
[dim_0087] [int] NULL,
[dim_0088] [int] NULL,
[dim_0089] [int] NULL,
[dim_0090] [int] NULL,
[dim_0091] [int] NULL,
[dim_0092] [int] NULL,
[dim_0093] [int] NULL,
[dim_0094] [varchar](12) NULL,
[dim_0095] [varchar](12) NULL,
[dim_0096] [varchar](12) NULL,
[dim_0097] [varchar](120) NULL,
[dim_0098] [varchar](120) NULL,
[dim_0099] [varchar](120) NULL,
[dim_0100] [numeric](20, 0) NULL,
[dim_0101] [varchar](20) NULL,
[dim_0102] [varchar](20) NULL,
[dim_0103] [varchar](20) NULL,
[dim_0104] [varchar](20) NULL,
[dim_0105] [varchar](20) NULL,
[dim_0106] [varchar](20) NULL,
[dim_0107] [varchar](20) NULL,
[dim_0108] [varchar](20) NULL,
[dim_0109] [varchar](20) NULL,
[dim_0110] [varchar](20) NULL,
[dim_0111] [varchar](20) NULL,
[dim_0112] [varchar](20) NULL,
[dim_0113] [varchar](20) NULL,
[dim_0114] [varchar](20) NULL,
[dim_0115] [varchar](20) NULL,
[dim_0116] [varchar](20) NULL,
[dim_0117] [varchar](20) NULL,
[dim_0118] [varchar](20) NULL,
[dim_0119] [varchar](20) NULL,
[dim_0120] [varchar](20) NULL,
[lastLoad] [datetime] NULL
) ON [PRIMARY]
-- Index example
CREATE NONCLUSTERED INDEX [idx_dim_0001 (not unique)] ON [z005497].[tblMatrix]
(
[dim_0001] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
-- The configuration table from which developers would find out what is in the Matrix
CREATE TABLE [z005497].[tblMatrixCfg](
[dimId] [int] IDENTITY(100000,1) NOT NULL,
[colName] [varchar](25) NOT NULL,
[dataType] [varchar](25) NOT NULL,
[dimName] [varchar](25) NOT NULL,
[dimDesc] [varchar](500) NOT NULL,
[dimpath] [varchar](5000) NOT NULL,
[loadDate] [datetime] NOT NULL,
[modUser] [varchar](100) NOT NULL,
[modDate] [datetime] NOT NULL,
CONSTRAINT [PK_tblMatrixCfg_1] PRIMARY KEY CLUSTERED
(
[dimId] ASC,
[colName] ASC,
[dimName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
Kill it if you can.
Also, that developer needs a lot more experience. And he/she should get it at another company.
It's basically violating so many things I don't know where to start.
Even if you end up fighting a highly normalized model which is following someone's best practices slavishly, it won't compare to the disaster which this design is going to create.
Just to give one example of what Cade meant with "I don't know where to start" :
"today column dim_0001 is customer name, but tomorrow maybe something else"
This typically also means that in the User acceptance system, dim_0001 can be customer name (and the system might seem to work and get accepted), and then you move to production, and dim_0001 gets to be name of the president's wife or so, and then hours of meetings need to be spent trying to figure out (a) where the problem is, and (b) how to get it fixed in as little time as possible.
( (b) usually amounts to patching the code with stuff like "if col_name = dim_0001 then don't treat it as what the matrix says it is, but treat it as what is hardcoded here instead".)
"What use is there for the Matrix?"
Well, I certainly don't get it.
I have never seen anything like this before and I don't understand how it is meant to be used or how the indexes is meant to speed up anything or how it is possible to query this table without using at least self joins.
Call me inexperienced if you like but this is a first for me. I would think that if this is the way to do things, the db vendors should not put so much effort into allowing us developers to define tables, with columns that have different data types, with relationships.
This is the result of trying to stuff an object oriented paradigm into a relational system. Document databases allow for this sort of programming:
Documents inside a document-oriented database are similar, in some
ways, to records or rows, in relational databases, but they are less
rigid. They are not required to adhere to a standard schema nor will
they have all the same sections, slots, parts, keys, or the like. For
example here's a document:
FirstName="Bob", Address="5 Oak St.", Hobby="sailing".
Another document could be:
FirstName="Jonathan", Address="15 Wanamassa Point Road", Children=[{Name:"Michael",Age:10}, {Name:"Jennifer", Age:8},
{Name:"Samantha", Age:5}, {Name:"Elena", Age:2}].
Both documents have some similar information and some different.
Unlike a relational database where each record would have the same set
of fields and unused fields might be kept empty, there are no empty
'fields' in either document (record) in this case. This system allows
new information to be added and it doesn't require explicitly stating
if other pieces of information are left out.
Trying to use this paradigm in a relational database is a "square peg, round hole" problem. A document database might be excellent for a highly transactional system, but analysis would be better served by loading the transactional data into various fact tables in a data warehouse.