![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
Fulltext articles in a database?
- Thread starter Fryguy8
- Start date
There are arguments for both ways.
Pro-in-DB
1) Only 1 place to manage the info
2) Easier to set up an online editor (IMHO)
3) don't have to worry about updating the DB if the physical files move.
Pro-link-in-DB
1) Size of DB (Some are limited to 4GB)
4) Speed. Most web-servers will cache a text file if it's requested. A bit more to do so on
a DB server
Please add to my list
For a comparison IBM Content Management Server allows files to be stored in the DB2 database. I know of several that were over 3 or 4 tera and they seemed to do alright.
Pro-in-DB
1) Only 1 place to manage the info
2) Easier to set up an online editor (IMHO)
3) don't have to worry about updating the DB if the physical files move.
Pro-link-in-DB
1) Size of DB (Some are limited to 4GB)
4) Speed. Most web-servers will cache a text file if it's requested. A bit more to do so on
a DB server
Please add to my list
For a comparison IBM Content Management Server allows files to be stored in the DB2 database. I know of several that were over 3 or 4 tera and they seemed to do alright.
Modifying the linked file, if your application does that, is a problem. How do you get the changes in the file to be involevd in the transaction with the database? It's not undoable, but it's not intrinsic -- like it would be if you had kept everything in the database.
You'll have to implement locking over the file by carefully coding your file I/O calls instead of just letting the DB handle locking over the record. DBs handle record locks all day long: it's what they do.
Getting a synchronized snapshot backup is just about impossible if you split the content between the database and the file system.
You'll have to implement locking over the file by carefully coding your file I/O calls instead of just letting the DB handle locking over the record. DBs handle record locks all day long: it's what they do.
Getting a synchronized snapshot backup is just about impossible if you split the content between the database and the file system.
Shouldn't pay TOO much of a penalty. I use it for one of my websites for handling alot of images in my galleries. Seems to do okay. The server that runs the servlet for retrieving the images is an old Proliant 1600 with dual 300 procs so it's not exactly a hot rod and it does fine.