On the morning meeting with the guys. We spent the first little bit getting caught up and bringing everybody up to speed on the different things that happened over the weekend. Alan was reporting on his findings with the data 8 server (locking tables) as well as the data recovery for a single client on data 0 (re-building back data from a back-up). Steve then asked some questions about the customers table. We got into a fairly lengthy discussion about table joins, corp-specific tables, number of records, caching data, storing quick access records in the session scope, and the difference between cached data and live data.

Steve, Alan, and I talked about splitting up the customers table into a corp-specific table. That is a pretty big project, but it could have some real benefits. Currently, there are about 250 (ish) tables in the database. Most of them are what are called shared tables. We basically put all of the data into the same tables and then specify what corporation gets what data (invisible fences or virtual sandboxes). We currently have 5 corp-specific tables (super high traffic areas). They are for things like the customer queue, invoices, po/invoice line items, invoice payments, and sub inventory. There are also some other corp-specific tables, but it depends on what 3rd party solution have been turned on. Long story made short, the main customers table seems to be the next candidate to do some work on. It's not the number of records in the table... that is relatively small (ish), it's the number of joins and connections that make that table a super high traffic area. The other two table that are getting some high traffic are the customer history table and the invoice history table. Both of those pieces are not as critical, but they are getting thousands and thousands of new records every day.

The main customers table connects with invoices, quotes, elements of time, customer queue records (who is next), and all of the normal CRM (customer relationship management) stuff like additional contacts, log notes, settings, reports, and histories. The main customers table is a huge access point. We allow corp-wide settings to be used on the naming of the customers. This allows for things like patients, members, students, clients, etc. Lots of moving pieces.

Anyways, we talked about some pro and cons of making some changes there. We anticipate that a major re-write, without going to crazy levels, would be two weeks to a month. I did a local search for the phrase "customers." (customers dot like a table join) and got almost 400 pages on my local box. Some of those pages have between 25 and 50+ instances or occurrences per page. It could be a pretty big project, for sure. I'll bet that within the week or starting of next week, we'll get someone on that project. We are going to need it sooner than later. It works great now... it just needs to be able to scale a little bit better. Build and break, build and break. That is what we do.

After our morning discussions, we broke into mini work sessions on our different projects. I paid some bills, recorded some expenses, made some notes and recorded those notes, and went through emails.