It's impossible to tell without knowing your use cases.
Aggregate root represents a logical unit on which actions can be executed as a whole.
If the order can stand alone, that it should be an aggregate root. If it can't, then it shouldn't. E.g. LineItem makes no sense outside of order. However, order usually can be used without customer object - e.g. your shipping department can mark the order as shipped, regardless of customer, so typically it is an AR.
If you try to do DDD (for good or bad), then your design shouldn't be driven by underlying data technology and table layout. Who says you need to use an RDBMS?
The seminal book on DDD is, of course, Eric Evans' "Domain-driven design" which provides lots of context which usually gets lost when people start to cargo-cult DDD.
Jimmy Nilsson's "Applying Domain-Driven Design and Patterns" book is also frequently recommended, but I don't find it quite that good personally.
DDD is useful when you have complex domain with lots of business rules and behavior/logic which is not encoded in entity state. Most applications are far simpler than that and there are better design alternatives.
I suggest reading Martin Fowler's excellent book "Patterns of enterprise application architecture" - it covers wider area than DDD books and offers many good approaches for handling the application behavior, as well as covering all the application layers, from backend to GUI.