Jump to content

hitman6003

Members
  • Posts

    1,807
  • Joined

  • Last visited

Posts posted by hitman6003

  1. By extending Zend_Auth_Adapter to be customized you can then return back a Zend_Auth_Result object that has whatever username you want...get if from the database for instance.  Then, when you call Zend_Auth::getIdentity(), it returns the valid username, not the incorrect one.  By breaking the functionality of getIdentity() (by it not returning a valid identity), you make things much more complicated for yourself...and whatever unlucky sap has to fix/extend your stuff in the future.

  2. I don't see anything wrong with your file write code.  If you are using php5 you can use the file_put_contents command, which is somewhat easier to read (and only one line).

     

    function void_case_statement($search_for, $replace_term, $filename){
    
    $search_for = "\"$search_for\"";
    $replace_term = "\"$replace_term\"";
    
    $old_size = filesize($filename);
    
    //read contents and add new text
    $file = file_get_contents($filename);
    
    // update the file
    $new_size = file_put_contents($filename, str_replace($search_for, $replace_term, $content));
    if ($new_size) {
    	echo "File successfuly modified!";
    }
    
    echo  "Old file size was: " . $old_size . ".\n"
    	. "New size is " . $new_size . ".\n"
    	. "Expected size is: " . (($old_size - strlen($search_for)) + strlen($replace_term)) . ".";
    
    }  

  3. the memory that marklarah is talkin bout is the memory taken from the database. you see, if you store only the path, the memory eaten is less compared with the picture itself.

     

    Again, just storing information in a database does not cause it (i.e. the database or the table) to consume RAM...the only time data is stored in RAM is when the column is indexed.

     

    Of special interest here is InnoDB's B-Tree indexes.  The leaves for an InnoDB primary key index store the data itself, so long as it doesn't exceed the size of the leaf (which, if I recall correctly, is 16KB), and the field is not a, or variant of, TEXT or BLOB (might be others that I don't remember off-hand).  Secondary indexes store pointers to the primary key, which in turn, follows the above behavior of storing the data in the leaf.

     

    MyISAM indexes, conversely, simply index the column and store a pointer to the data on disk. 

     

    we don't need to give the database server additional unnecessary effort, especially if the server itself is already too full of itself

     

    Agreed, wholeheartedly...databases are much more expensive that web servers...they require higher paid admins, better storage, more RAM/CPU...so fiscally speaking, it doesn't make sense to use them for something as mundane as image serving.  However, it's not impossible, and in some cases, is needed (what the easiest way to securely store documents without having to encrypt each one individually?  Dump them into an encrypted table).

  4. Ah but I'm using the object oriented approach, so like:

     

    makes no difference...

     

    function mysqli_conn() {

    $host = "localhost";

    $user = "xxxxxx";

    $pass = "xxxxxx";

    $db = "dev";

     

    return new mysqli($host, $user, $pass, $db);

    }

     

    function query($sql, $db_connection) {

    return $db_connection->query($sql);

    }

     

    $database = mysqli_conn();

     

    $result = query("SELECT * FROM tablename", $database);

  5. How big is your MyISAM buffer?  Is it big enough to fix the fulltext index in memory?  If not, consider creating a buffer specifically for that index (assuming that the table and search speed is that vital to operations).

     

    I think you have two options otherwise...use MySQL6's Falcon engine, which has a new (better!) fulltext index, or use an external fulltext index, such as Lucene or Sphinx.

     

    The limiting factor is probably MyISAM's fulltext index itself, since the table is fairly large and I can only assume that a large part of that data is in the description (which is indexed, thus creating very large indexes).

     

     

  6. Storing images would take up memory

     

    How would it use memory (I'm assuming you mean RAM)?  Unless you are indexing a blob...which is pointless (and I'm not sure it's possible). 

     

    , and not to mention space.

     

    They are going to use HDD space regardless of where they are stored.

     

    It also increases the query times.

     

    Again, how?  It may increase the amount of time it takes the query results to move across the network from the DB server to the web server, but the query times would not be impacted.  The exception to this may be if you issue a query with a WHERE clause on an unindexed field and MySQL has to do a full table scan, which would cause it to have to read all the data off the disk.

     

    If you store text, it makes things easier (it also requires no headers)

     

    The easier part is a matter of opinion...some people prefer to just backup the database and not have to worry about a huge file system.  The headers part is true...when you have the image stored in the DB you have to have a seperate php script to query the database for the image data, then issue image headers and stream the data to the browser.

     

    and so you can adjust how you want your images to be (size, hieght etc)

     

    That can be done regardless of where the image is stored.

     

    Where to store the images is a matter of opinion primarily.  There have been many many arguments between people about which is better.  I, personally, use the file system.  Database's generally have expensive storage...where I work the Apache servers have 10k SATA drives, the DB servers have 15k SCSI drives...and depending on what else the database is doing, you may not want it to have to devote CPU cycles to querying and sending images...it's much more difficult (generally speaking) to add additional computing power to a DB (horizontal scaling is one of the few options), however it's very easy to stand-up a new Apache server to server static images.

     

  7. Okay, turns out I just needed to put "global $mysqli;" at the top of the function to make the variable global. Is this fine to do security wise?

     

    Security wise, there is probably no harm done.  However, it's generally considered bad practice to pollute the global name space (at least as much as you can consider it a name space in php...).

     

    Why not just return the mysqli object from your function?

     

    function mysqli_conn() {
    $host = "localhost";
    $user = "xxxxxx";
    $pass = "xxxxxx";
    $db = "dev";
    
    return new mysqli($host, $user, $pass, $db);
    }
    
    function query($sql, $db_connection) {
    return mysqli_query($sql, $db_connection);
    }
    
    $database = mysqli_conn();
    
    $result = query("SELECT * FROM tablename", $database);
    

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.