This is what I already know:
Tables for open invoices: "CustTransOpen" - "CustInvoiceJour"
Now, I need some way to find all the lines that make up every single invoice. I've been researching and found that the tables custInvoiceLine and custInvoiceBackorderLine seem to hold this kind of information, but it's not exactly what I need.
Am I heading in the right direction?
The easy way to find is go to form and see its data sources in AOT. In this case CustInvoiceJournal where you can see CustInvoiceJour and CustInvoiceTrans(Lines table) and related tables.
Related
I thought I'd ask before I try to build something from scratch.
Here is the type of problem I need to answer. One of our researchers comes to me and says "How many people in our data have such-and-such SNP genotyped?"
Our genetics data consists of several dozen GWAS files, typically flat delimited. Each GWAS file has between 100,000-1,000,000 SNPs. There is some overlap in the SNPs, but less than I'd originally thought.
Anyway, what I want to do is have some sort of structured database that links our participant IDs to a particular GWAS study, and then link that GWAS study to a list of SNPs, and I can write some kind of query that will pull all IDs that have the data. At no point do I need individual level genotype data, it is way easier to pull the SNP/Samples that I need once I know where they are.
So that is my problem and what I'm looking for. For anyone who works with a lot of GWAS data, I'm sure you're familiar with the problem. Is there anything (free or paid) that is built for this type of problem? Or do you have thoughts on what direction I might want to go if I need to build this myself?
Thanks.
I have two database tables where there is a one to many relationship. I would like to show the data via model-view architecture in Qt where one clicks the plus sign on the view and the rest of the relational data is displayed below. What is the better way of implementing this? Will QTreeView or QSQLRelationalModel be sufficient for this implementation?
Thx in advance
I conducted some search as to the better implementation of this case, and I was able to display two seperate tables via QStandardItemModel and QTreeView.
For columns that do not match I just left blank and I increased the number of columns in QStandardItemModel so that it includes the desired columns from both tables.
I thought the information might be useful for those looking for an answer for this question.
Sincerely
P.S. My points were decreased by 2 points for this question. I just wonder why my points are decreased for asking a question.
I use stackoverflow a lot, but this is my first question here, so if i'm doing anything wrong just let me know. I'm not a programmer (I just do programming for my own needs) so I'm open to tutorial suggestions etc. I won't be offended if you just give me something to read and find the answers myself.
OK, to the point - I'm trying to write simple application to track my personal expenses and I have a problem with database design. I'm using VStudio to create the database (SQLite). I attached a diagram with my design and I have some questions.
My SQLite diagram
I don't know exactly how to design "Transactions" table. Fields like Date, Payment Type etc. seems to be easy enough but the idea was to store in this table information about transactions so I need to store multiple products there. I've read about it and created table "Transactions_Products" that will help with that. My problem is : where do I put quantity of products in the transaction? I can't think of a place to put it. I tried to find similar databases but couldn't find anything.
Second thing. I've read about indexing a lot, but I still can't grasp the idea. I don't know when to use it. Should I use it only on fields that I will be "querying" a lot?
Last one - is it better for such a small application just for myself to store my account balance in a separate table or should I just calculate it every time?
As I said, I don't need answers like: "do this, do that". If you just give me some good tutorials/articles I think I can find answers on my own, but I couldn't find it. Maybe I'm searching for it wrong.
Thank you in advance for any information.
where do I put quantity of products in the transaction?
Transactions is a bad table name as it's vague and has multiple meanings. Consider "payments", "purchase invoices", etc. See https://dba.stackexchange.com/questions/12991/ready-to-use-database-models-example/23831#23831 for some existing patterns.
Should I use [indexes] only on fields that I will be "querying" a lot?
There's no free lunch. Indexes take space, and can slow down inserts. Start with indexes on your primary keys (which is the default for SQLite), measure what is slow (looking at query plans) and add indexes if they help and if you have room.
is it better for such a small application just for myself to store my account balance in a separate table or should I just calculate it every time?
For an operational/transactional database like you describe, avoid storing calculated values. SQLite can count numbers quickly :)
Premature optimization is premature. Make it work first with full normalization. If you have performance problems, analyze what is really causing the slow-down and go from there.
I have been tasked with creating a product inventory module. After reading all the posts I can find on Stack Overflow, I have decided the best way is to not keep a separate, running ‘balance’, but to create one on the fly. I have attached a representation of the tables involved.
Actually, it seems like I don't have enough reputation points to include a picture, so here is a link to a dropbox file:
So I have two questions, which are somewhat related, so it seem like I should include them in the same question posting, though I am not a frequent poster and a sql noob. So please excuse me if I am displaying my ignorance with posting or sql.
First, does this look correct (I named all the columns as non-opaque as possible)? I have to create reports that show the current inventory balance for all the products and for products individually as well as a ‘Transaction Register’ with running balance.
Second, provided the first answer is yes, is this a good candidate for creating a view?
Complex question. Difficult to answer without understanding the full scope of the project. One point - I see there is no Current On-hand table. I agree that the running balance at any point in time is best to use a calculated table. It is however common practice to keep a current on-hand table. This gives you the on hand inventory and values with-out having to sum up the transaction. This is the approach in Microsoft Axapta, and other products I have worked with.
A lot of duplication has crept into a client's database through poor initial design. I am writing some stored procedures to merge users etc. It would be nice to accomplish the merge and still be able to do an undo or a rollback without doing a full database restore.
My original question was how much other housekeeping or record keeping do I need to do, and how do I do it? I think I've addressed that. The question now is whether there is anything beyond the following that needs to be done. I realize now this was a poor type of question for this site. In compensation for that, I'll offer to share my experience with anybody who also needs to build a duplicate record merging tool.
The basic pseudocode for a merge is:
Let from_id = the record to merge (the mergee). Let into_id = the record that all the from_id references need to point to after the merge.
Check the database schema against known parameters and return a schema_changed error if changed.
Use information in merge_config and merge_referrer_config tables to add an entry to merge_log and merge_referrer_log tables to give detailed instructions for every piece of data that needs to be changed to accomplish the merge. This log becomes the instructions for a rollback (undo). The config tables give complete information about everywhere the merging records are referenced in the database.
Follow the instructions just added to the merge log tables to update all pertinent (as defined in merge_config and merge_referrer_config tables) tables to set pertinent columns = into_id where pertinent column = from_id.
Mark the merged_to column of the record for from_id with the into_id.
Thanks,
Tom
Well you should do a back up anyway, in case something goes horribly wrong.
In terms of an audit trail, I'd be tempted by a duplicates table, with an extra column for when it got 'merged' out then house keep that. Say chuck any thing more than X old from duplicates before a merge run. Another option I've seen, is a weighting put on how different the records are. "Exact duplicate" is 0 everything different but the key is a 100. Then chuck / keep based on the weighting.
Whatever approach you take, look at it on the basis of you audit every sniff at the start and then as "you" get a feel for the data, you can silently bin it, or look at prioritising for critical weaknesses in the system