I am working on my website where I sell concert tickets.
I am working on designing the part of the website where I generate tickets based on seat and rows available.
After some thinking and drawing I have to the conclusion that this design would be best for my problem.
I was wondering is this poor design or are there any improvements that I can make?
Thank you
I wouldn't expect to have a table of unbooked seats. A table of bookings seems more logical. Your concerts table looks questionable if you expect to have a series of dates for the same concert.
Perhaps you should first sketch out the key functions of your site as User Stories or Use Cases and list out the required attributes for each. That could give you a better set of requirements for your database design, e.g. what customer attributes; what about seat attributes such as restricted view, standing places or accessible places for the disabled.
Related
In my company (train company) there is a sort of battle going on over two viewpoints on something. Before going to deep into the problem I'm first going to explain the different domains we have in our landscape now.
Product: All product master data and their characteristics.
Think their name, their possible list of choices...
Location: All location master data that can be chosen, like stations, stops, etc.
Quote: To get a price for a specific choice of a product with their attributes.
Order: The order domain where you can make a positive order but also a negative one for reimbursements.
Ticket: This is essentially what you get from paying the order. Its the product but in the state that its at, when gotten by the customer.
The problem
Viewpoint PURPLE (I don't want to create bias)
When an order is transformed into all "tickets", we convert the order details, like price, into the ticket model. In order to make Order something we can throw away. Order is seen as something transient. Kind of like the bag you have in a supermarket. Its the goods inside the bag that matter. Not the bag itself.
When a reimburse flow would start. You do not need to go to the order. You would have everything in the Ticket domain. So this means data from order will be duplicated to Ticket.
But not all, only the things that are relevant. Like price for example.
Viewpoint YELLOW (I don't want to create bias)
You do the same as above but you do not store the price in Ticket domain. The ticket domain only consist of details that are relevant for the "ticket" to work. Price is not allowed in there cause its a thing of the order. When a reimburse flow would start, its allowed to go fetch those details from the order. Making order not something you can throw away as its having crucial data inside of it.
The benefit here is that Order is not "polluting" the Ticket with unnecessary data. But this is debatable. The example of the price is a good example.
I wish to know your ideas about these two viewpoints.
There is no "Don't repeat yourself" when it comes to the business domain. The only thing that dictates the business domain is the business requirements. If the requirements state that the ticket should work independent of the order changes, then you have to duplicate things.
But in this case, the requirements are ambiguous. There is no correct design using the currently specified requirements. Building code based on assumptions is the #1 way of getting bad code, since you most likely will have to do a redesign down the road.
You need to go back to the product owner and ask him about the difference between the Order and the Ticket.
For instance:
What should happen to the ticket if the order is deleted?
What happens to the order and/or ticket if the product price changes?
What happens to a ticket if the order is reimbursed?
Go back, get better requirements and then start to design the application.
Our company has two lines of business - a project side and a pure product side. We want to track each as seperate P&Ls, particularly gross profit. Is there a recommended way to do this in NetSuite? For example, we were thinking of creating two departments, one for Products and on for Projects, but that doesn't really work because POs may contain parts for both sides of the business. Is there an intended mechanism for tracking different business units?
You might want to look at expense allocation. You can set up allocation templates so that overhead expenses are allocated by department or location.
Other than that if your parts are not some sort of consumable/overhead I'm guessing your purchasing is a little off or your project and product businesses are not that separate.
In my current application, which is quite simple, I have a class responsible for keeping track of all the customers. It adds new customers, updates details, assigns managers etc. All in all, it performs some logic and keeps track of what is there.
Now, I need to display this database in a complicated way, with certain string formatting, column widths etc. Should this behaviour be part of an external class that would take a list of cusomers, or should it rather stay within the Database itself, as it is the "closest" to the customer objects? What are pros/cons of both approaches? What makes more sense semantically?
Thx in advance.
I would use an external class because the code will be reusable for other applications. If you tie the formatting to the database, then you'll end up with very specific code that will cost you time further on down the road.
That being said, the elegant solution is not always the fastest. If there's a looming deadline, and you find it easier and faster to hard code your formatting info, then it may be more prudent to brute force your way through it so you don't end up with an angry client, an unfinished project and an unpaid invoice.
I'm working on a project for a customer, and one of the requirements is that Users should be allow to assign to each Product (in their case, a Node) a Country or a Region, where the Region is simply a group of Countries, not necessarily in the same area.
I've seen there are many different ways to manage a list of Countries, often suggesting to use Taxonomy for them, but I can't figure out how could I allow users to create these "Regions". To make things complicated, customer wants to have a simple interface, where only one field is present on the form. In this field, Users must be able to choose either a Country or a Region.
Perhaps I could implement everything using Nodes, i.e.:
- Country Nodes
- Region Nodes, with a multiple-valued Node Reference to Country Nodes
But I wonder if that would not be too heavy...
I hope the issue is clear, if not feel free to ask and I'll try to explain it better. Thanks for all suggestions.
I ended up creating my own tables and code to handle the whole thing, as I couldn't find any better solution. I used tables from IP2Country module as a source for Country Codes.
I'm curious to know where people value Data Aggregation. I'm truly curious, if you don't mind letting me know how important this really is to you personally with respect to your work environment, and if you have to work directly with data agg in your line of work.
Really interested to hear about your feedback.
If you persist data (e.g. store it in a database) chances are that the data will be used by managers, statisticians, stake holders etc. to analyze the workings of their software-supported undertaking to make executive decisions. This analysis can only take place by methods of aggregation. There's no one in the world who can look at a million rows of raw data and glean insight. The data has to be summed, averaged, standard deviated etc. to make any sense to a human being.
A few examples of areas where data aggregation is important:
Public Health (CDC, WHO)
Marketing
Advertising
Politics
Organizational Management
Space Exploration
lol. Take your pick!
Very important, what else is there to say?
I work at a large hospital and not only do we have numerous departments using Analysis Services cubes we develioped but they rely heavily on the daily totals and different aggregations they can derive from these cubes by simple browsing. Without the very basic capability of being able to aggregate on some portions of your data you might as well write it on paper (IMO).
Say you have data over every individual sale.
Looking at these individual purchases could be interesting some level level(e.g. whne a customer comes and wants a refund)
However, I cannot send those 20 million records to my boss at the end of each month and say "Heres how much we sold this month".
This data needs to be aggregated and summarized on various levels. The business would not operate if the marketing guys couldn't get an aggregate for each product, the regional boss couldn't get an total aggregate over a time period and so on.
Our databases have millions of rows, of course we rely on aggregation for managment information, not to use it would be to put too heavy a load on the database in order to run large reports which would impact heavily on the users of the database. I can't think of many cases where the database contains business critical information that managers use to make decisions where aggregation would not be needed for managment reports.
I view data aggregation like data in a grid and being able to group, order, and sort columns. In a large grid of data, this is very important. It's really the difference between looking at a pile of numbers and looking at meaningful data.