Tag Info

Hot answers tagged

5

I do not have enough brownie points to comment so I will leave an answer. Keep in mind that the works of Shakespeare were written by a single human for human consumption. I think you should expand your horizons a little and consider machine generated text of which humans are only intended to read parts of. For example, looking inside the /var/log/ ...


4

Systems such as RabbitMQ (or in your case maybe look into Kafka) can offer persistence, or guaranteed delivery, as well as configurable TTL on messages. However, they are not designed as a long-term persistent storage solution, and if we're talking about days, I would actually store the job in a DB as you suggest.


3

It is a matter of opinion. You might use postfix representation (à la RPN, or even some stack-oriented programming language), or some bytecode (specific to your expression language), or some s-expr syntax, if you want some more compact representation. JSON is probably a less compact textual representation but it is very widely used (and you've got many ...


3

An alternative to @Thomas comment (which is viable, although imo recursive foreign keys add too much complexity if you do not need the additional power they give) would be to create separate tables for each foreign-key type (one for students, one for groups), allowing for enforceable foreign keys: Rules: |id|rule | |--|----------| | 1|Bus at 7am| -- ...


3

In an app like this the "tiers" are usually various parts of the same application. You could write it as multiple JARs packaged into a single deployment, but the different tiers are more about separating the different concerns in the code than putting physical distance between them. If you were to put the data access on a separate machine, you would need ...


3

Config files should almost be the last places to put business rules or parameters. Config files should in general used only for administrative functions - things that DB admin or IT admin would control - certainly not the business logic. One of the key reasons why config files for business logic is bad is because typically business rules not only change in ...


3

You should look into one of the many embeddable pure java SQL dbs which you can embed and distribute with your app. Your existing SQL should work with those either as is or with minor modifications. Take a look at: http://hsqldb.org and http://db.apache.org/derby/


2

The data sync would be much better and faster, if it can be done on the basis of some kind of delta identifier or flag. Basically, you should update the target db data rows only when it is out of sync with the source db. In SQL server db, you can take the help of the Checksum fn also to build the delta based identifier. You should develop a SQL based job ...


2

The scenario itself: "a user views a video should increase view count" is a client side activity resulting in backend data changes. It is initiated by the user using the client app, so it is okay to put the code that initiates and increases of view count in the client app. However, here are some other/different ideas to consider: Keep using the client ...


2

As pvg has mentioned, a good option to use is an embedded database. The reason here is that the database can be included as a single JAR file, rather than needing to be installed on the system's user. Usually, you can access the databases using the standard JDBC API, so it really can act as a replacement for your current MySQL DB. The library will manage ...


2

Since you have the primary key of each record, I highly recommend using the approach of examining each record individually. Primary key lookups are extremely fast in any professional-grade database. Updating a record based on primary key has a very granular lock level and is fast. By inserting or updating rather than delete/insert, you maintain the ...


2

No Technically, it looks like there are some ways to connect directly to your database via HTTP (google "sql server http endpoint deprecated" and "ado.net data services") but you cannot hide the connection information if it is on the client. This is a crazy bad idea -- don't do it. One of the first rules of web app programming is that the client cannot be ...


2

Calculate your storage costs. Add the cost of high(er) availability, backups, version control. Look what S3 or Backblaze or whatever else would charge for this amount and traffic; compare to having your own servers / NAS / SAN / datacenter (I don't know your volumes). Then compare that to the cost of hiring a qualified developer / sysadmin to create and ...


1

Typically fetching is not an issue for concurrent read requests. When it comes to thousands of concurrent writes usually the systems are designed to prevent from more than a few concurrent write access to given record at any given time. When it comes to concurrent write access it's mostly boils down to DBMS record locking, via transactions.


1

I agree with Snowman and think you should do all the queries. Along with performance being negligible, you can gain some insights about the data changes that may benefit you and/or users: New Categories Removed Categories Categories that have changed. Someone is eventually going to ask what happened. "We got a new file," won't be enough.


1

... i could generate the data when the user is registered and then store it to database, or generate it every time it is requested. This sounds like two completely different operations to me: 1) Generate [static] "image" data when the user registers and store it in a database. 2) Generate some dynamic "image" data whenever the user visits a page. ...


1

I would say the easiest way is to store it physically : you don't need any kind of handler or database call to retrieve the image, further managing will most probably be easier aswell as client-cache handling. There's actually not a lot of good reasons to clutter your database with images, so I would say this alternative is only just acceptable in some ...


1

What you probably want to do here is use a repository... This would have your querying methods directly related to your Object and would use and instance of the DB as part of its constructor: $repo = new MovieRepository($db); $movies = $repo->findAll(); And or writing you might have: $repo = new MovieRepository($db); $movie = $repo->findById($id); ...


1

For a desktop application, it's usually better to deliver everything the end user will need in a single package. End users tend to dislike dependency requirements, because it only takes one or two conflicting packages requiring different versions of the same thing to completely ruin your day. For a single-user application, you're probably best off using an ...


1

If you're just learning, I recommend that you put the details of deployment to one side at first and just assume that the database will always be there and will always be in the correct format. Once you've got your application to a state where you're reasonably happy with it, then you can address your concerns regarding the database. When you do get to ...


1

Yes, I have seen significant performance problems result from this sort of pattern. If you have branches in your sproc that result in making significantly different queries, under certain circumstances this can cause huge performance problems. SQL server will build an execution plan for a sproc when it needs to based on the values of the parameters passed ...



Only top voted, non community-wiki answers of a minimum length are eligible