I am not a programmer, but I have been tasked with making a basic accounting app for a small business.
I was looking at pbooks, but I am not sure this is customizable enough for my needs.
I need to be able to count each day how many food items are sold, how many drink items, how many guests, and then tie orders of food and drinks to guests if it is a guest that purchases it.
Is pbooks customizable enough to do this? Using the live demo you do not seem to be able to generate reports just for dates, or for certain customers..., perhaps there is a better bookkeeping solution?
Otherwise, I think I have enough mysql knowhow to do this, and theh php code should mostly just be getting the queries right.
Right?
Additionally, can anyone recommend a live demonstration of such a system?
I have not been able to find any live demos where I can demonstrate how you can generate reports for a given time period, or show the total sales for a guest or such.
I need to demonstrate this to show why it is a much better solution that an ever expanding mess of an excel workbook....
Hire a programmer
Seriously. It will cost less and be done faster and correctly. I would agree that just about anything is better then an Excel spreadsheet but a beginners rendition of an accounting application is not one of them.
Otherwise, I think I have enough mysql
knowhow to do this, and theh php code
should mostly just be getting the
queries right.
Right?
Wrong
The PHP code will be much more complex then simply "getting the queries right."
Additionally, can anyone recommend a
live demonstration of such a system?
I have not been able to find any live
demos where I can demonstrate how you
can generate reports for a given time
period, or show the total sales for a
guest or such.
If you can't install free, open source, community backed software on your own then you should not be tasked with this job.
Again, my suggestion would be to either hire a programmer who knows exactly what they are doing or seek support from the community for which projects you are interested in. This is not a discussion forum.
There's phpBMS or online service like Freeagent or Freshbooks which are good options if you need to use the package for IRS returns, because they're kept up to date with the latest tax rules
http://www.nolapro.com/
Try it it's free web-based accounting software.
http://bambooinvoice.org/
I've seen this employed with reasonable degrees of success for smaller scope accounting (keeping records, emailing invoices, generating pdfs). It's built under CodeIgniter so if you're familiar with that framework's approach to MVC it is also reasonably extendable.
You need a POS system, not an accounting system
I just came across Akaunting - being continually updated as of 2020. I haven't tested it yet.
Also ran into Simple Accounting System but looks sort of simple and disorganized from looking the files on sourceforge. Haven't actually tried it. Also hasn't had updates since early 2015.
Related
I work for a small company who wants to expand an existing system but by doing so there are also some issues.
The system itself is used to store images and video's.
Always being available
So we talked to our host and they recommended us to use Ceph and Cassandra. Now I did some research on both of them and I really like the idea of Ceph - but Cassandra.. well, it would take a while for the existing system to be adapted to it.
The reason they recommended Cassandra was so our database would always be available. Now - the DB won't increase massively, it would only be used to keep some user-info, image-tags and other small meta-data.
Another issue is that many queries use "like" in order to find the tags. CQL does not support this.
Now we don't have any developers who have knowledge of Cassandra so it might take some time to take used to that.
My question
Is there an alternative for Cassandra, preferred a relational database (so not NoSQL)
which is still highly available (like when one server goes down,
another takes over).
In case there isn't - how long would it take to get used to Cassandra's query language for relatively inexperienced developers (~ 1 year of experience), including the knowhow of how to adapt a system to it.
Just in case I didn't do my research properly, is Cassandra even the system we are looking for, the DB is pretty much only used for storage and some small functions.
In case you recommend a NoSQL language, what other options do I have of searching and finding data (as we now do by using " ..where x like 'something'")
Another issue is that many queries use "like" in order to find the tags. CQL does not support this.
It does, since Cassandra 3.5 with SASI secondary index
Now we don't have any developers who have knowledge of Cassandra so it might take some time to take used to that.
It's not a problem, you have hours of free online video and training at Datastax Academy
In case there isn't - how long would it take to get used to Cassandra's query language for relatively inexperienced developers (~ 1 year of experience), including the knowhow of how to adapt a system to it.
Just watch the data modeling videos, you should grasp quickly the fundamentals ideas behind Cassandra data model.
Just in case I didn't do my research properly, is Cassandra even the system we are looking for, the DB is pretty much only used for storage and some small functions.
If you're looking for extreme high availability (0 downtime) Cassandra is for you.
If you can handle a downtime of some minutes, there are also other systems that can be a good fit.
I have currently 100 stores each with separate database. I want to develop a web portal which will display all 100 stores and if someone wants to search he will get the products from 100 stores on this portal rather going to different store's website. i was using xml for this purpose but it taking too long to parse xml file and filter the records of each store according to search keyword. i was generating xml when any store add new or edit product record. And on the portal website i was just parsing these generated xml (using PHP) files.
Please guide me if there is any better solution other than xml parsing. Let me clear one thing that all these stores and portal are hosted on same server and using subdomain for each store.
Thanks in advance.
Use a single database. Distinguish between stores with a store table that you reference with a foreign key column in any table where it is relevant (which is likely only going to be the stock table).
My first piece of advice to you is this: HIRE SOMEONE! If you have 100 stores, you certainly have the cashflow to devote to some sort of development project that is managed and planned by a professional.
Secondly, you are looking for someone with extensive database skill and experience. Please take the time to hire the right person, then get out of their way and let them do the job. If there is one thing I have learned in my time in the business world, it's that the single greatest hindrance to a job well done by IT, is a "boss" that doesn't recognize when he needs to hand over the reins to someone else who knows better.
The best way to think of it is this... if you know nothing about databases, and you were to start TODAY to learn everything you'd need to learn to do it RIGHT, you could expend the equivalent of a few working years in doing that. Is it worth the loss of productivity for your business? Probably not. So pay a guy $60,000 to $80,000 depending on his capabilities, and have him do it for you. You get a final product that's far more certain to be done right and work well, and you get it sooner, so you can get a faster ROI.
As far as what technology to use? I'm not even going to try answering that... it's not really for you to know or decide. Hire the right person, and let them tell you what you need.
I think sphinxsearch fits to your requirement.
Sphinx is an open source full text search server which accepts input from various sources like mysql & xml.
IN your case you can use xml/mysql as input source for indexes.
Key point with sphinx is once your indexer is ready you search response will be very quick. You can update your indexes in real time (for new product added in system).
Hope this help.
~K
I've been working on a new site of mine for a couple of days now which will be retrieving almost all of its most used content from a MySql database. Seeming as the Database and website is still under development the tables are really small at the moment and speed is of no concern yet.
But you know what they say, a little bit of hard work now saves you a headache later on.
Now I'm only 17, the only database I've ever been taught was through Microsoft Access, and we were practically given the database completed - we learned up to 3NF, but that was about it.
I remember reading once when I was looking to pull data (randomly) out of a database how large databases were taking several seconds/minutes to complete a single query, so this just got me thinking. In a fraction of a second I can submit a search to google, google processes the query and returns the result, and then my browser renders it - all done in the blink of an eye. And google has billions of records to search through. And they're also doing this for millions of users simultaneously.
I'm thinking, how do they do it? I know that they have huge data centers, but still.
I realize that it probably comes down to the design of the database, how it's been optimized, and obviously the configuration. And I guess that's my question really. Could someone please tell me how to design high performance databases for millions/billions of rows (yes, I'm being optimistic), and possibly point me towards some good reading material to help me learn further?
Also, all my queries are done via PHP, if that's at all relevant to any answers.
The blog http://highscalability.com/ has some good articles and pointers to how companies handle large problems.
Specifically related to MySQL, you can Google for craigslist.org's use of MySQL.
http://www.slideshare.net/jzawodn/mysql-and-search-at-craigslist
First the good news... MySQL scales well (depending on the hardware) to at least hundreds of millions of rows.
Once you get to a certain point, a single database server will have trouble managing the load. That's when you get into the realm of partitioning or sharding... spreading the load across multiple database servers using any one of a number of different schemes (e.g. putting unrelated tables on different servers, spreading a single table across multiple servers e.g. by using the ID or date range as a partitioning key).
SQL does shard, but is not fundamentally designed to shard well. There's a whole category of storage alternatives collectively referred to as NoSQL that are designed to solve that very problem (MongoDB, Cassandra, HBase are a few).
When you use SQL at very large scale, you run into any number of issues such as making data model changes across a DB server farm, trouble keeping up with data backups, etc. That's a very complex topic, and people that solve it well are rare. For a glimpse at the issues, have a look at http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/
When selecting a database platform for a specific project, benchmark the solution early and often to understand whether or not it will meet the performance requirements that you envision. Having a framework to do that will help you learn about scalability, and will help you decide whether to invest effort in improving the data storage part of your solution, and will help you know where best to invest your time.
No one can tell how to design databases. It comes after much reading and many hour working on them. A good design is product of many many years doing them though. As you've only seen Access you got no knowledge of databases. Search through Amazon.com and you'll get tons of titles. For someone that's starting, anyone will do it.
I mean no disrespect. I've been there and I'm also tutor of some people learning programming/database design. I do know that there's no silver bullet or shortcuts for the work you have ahead.
If you intend to work with high performance database, you should have something in mind. The design of them in per application. A good design depends on learning more and more how the app's users interact with the system, the usage patterns, etc. The things you'll learn from books will give you options, using them will depend heavily on the scenario.
Good luck!
It doesn't all come down to the design of the database, though that is indeed a big part of it. The guys who made Google are geniouses, and if I'm not completely wrong about Google you won't be able to find out exactly how they do what they do. Also, I know that years back they had more than 10,000 computers processing queries, and today they probably have many more. I also suspect them for caching most of the recent/popular keywords. And all the websites have been indexed and analyzed using an unknown algorithm which will make sure the computers don't have to look through all the words on every page.
In fact, Google crawls the entire internet around every 14 days, so when you do a search you do not search the entire internet. Your search gets broken down into keywords and then these keywords are used to narrow the number of relevant pages - and I'm pretty sure all pages have already been analyzed for important and/or relevant keywords before you even thought of visiting google.com.
Have a look at this question.
Have a look into Sphinx server.
http://sphinxsearch.com/
Craigslist uses that for their search engine. Basically, you give it a source and it indexes whatever you want (mysql database/table, text files, etc.). If it works for craigslist, it should work for you.
Looking to integrate a web application with MYOB. There's not much in terms of documentation out there. I've found a couple of companies that provide middleware, but nothing promising. Just thought I'd see if anyone else out there has had experience with this and might be able to save me a bit of time.
Cheers
Depends what you want to do with the myob database.
Retrieve information is fairly easy, there is a myob odbc connector you can install.
Write permission requires you to be a myob developer partner, costs you a lot more per year.
I did a job to synchronize data from MYOB db to MySql. So all the updates in myob db is reflected in mysql, but not the other way around
You may want to wait...
MYOB is overhauling their 90's style application (netbios/etc), moving it to .net framework with an API (they said it would be done Q2 2009, moved to Q2 2010).
They have non complaint SQL syntax (insert/select), yes that's right only two keywords... (the idea is if you screw up the query, say to an invoice, you have to write a insert into the credit table)
Unfortunately, read/write functionality doesn't come with the MYOB licence. If I can remember correctly it was Read for AUD$250 one time and AUD$800yr for write permissions. Most companies can afford as it cuts down on labor.
The ODBC driver hard to use, because it executes the MYOB application and leaves it in the background. (you may want to create your own rest service to query)
I have submitted this previously but because someone down voted it and said it was already answered, no-one will answer it.
I know there are similar posts here:
Design question: How would you design a recurring event system?
What's the best way to model recurring events in a calendar application?
but they do not answer my request which is for a practical, simple and real-world example of logic for a recurring calendar setup, without using another framework or tools/scripts other than straight PHP and MySQL.
I do agree that this article http://martinfowler.com/apsupp/recurring.pdf is good, but it is so abstract that I cannot understand it.
I know there are other "Systems that have done this" but this is my own white whale, and I will figure it out at some point - I would just like some help along the way.
So, the question is: how do I build a recurring calendar using PHP and MySQL?
You should strive to understand the Fowler article. It really does cover it.
The fact of the matter is, this is a hard problem. Editing logic "on the fly" is not something users really want to do. Rather, they want you as a programmer to have anticipated what they'll want to do and provided a rule for it--they don't want to have to figure out how to compute the second Wednesday of the month, for instance.
It sounds like your real problem lies in modeling the recurrence in MySQL. You could use Google's spec, which can be stored in a database and covered on Stack Overflow before. Fowler's piece also provides some good starting points in terms of well-defined classes that can be represented in an RDBMS.
It's a hard problem. And while SO wants you to succeed, we can only lead you to the stream. We can't force you to drink.
For a practical, real-world example of recurring calendar logic, look at your PDA or equivalent.
I got to build a calendar in an intranet application a few years ago and basically copied what my Palm had for recurring options. It made sense to people, so I judged it a success. But it didn't store real clean in the database. My code ended up with lots of careful checks that data was consistent along with various rules to correct things if something looked awry. It helped that we were actively using it as I was developing it. :-)
As far as storage went, the calendar entry involved a flag that indicated if it was part of a recurring series or not. If it wasn't, it was a non-recurring entry. If it was, then editing it had a couple of options, one of which was to break the series at this entry. Recurring entries were put into the database as discrete items; this was a type of denormalization that was done for performance reasons. Amongst other things, it meant that other code that wanted to check the calendar didn't have to worry about recurring items. We solved the "neverending" problem by always requiring an end-date to the series.
Actually setting up the recurring items involved some JavaScript in the UI to control the different settings. The entry in the DB had a combination of values to indicate the scope of the recurrence (e.g. daily, weekly, ...) the recurring step (e.g. 1 week, 2 weeks, ...) and any variation (weekly let you say "Monday, Wednesday, Thursday every week").
Finally, we had some logic that I never got to fully implement that handled timezones and daylight saving. This is difficult, because you have to allow the shift to apply selectively. That is, some calender items will stay in time local to the end-user, others are fixed to a location, and either may or may not shift with daylight saving. I left that company before I got a fix on that problem.
Lastly, I'm replying to this because I didn't see all the other questions. :-) But go read and understand that PDF.