Dane binarne w MySQL [zamknięte]

186

Jak przechowywać dane binarne w MySQL ?

— Geoff Dalgas
źródło

1

storing-images-in-db-yea-or-nay

— juergen d

2

@Nevir: Jakich informacji szukasz? Czego brakuje ci w odpowiedziach @ phpguy i @ Mat ?

— eggyal

Przepraszam, nie miałem zamiaru go nagradzać (napotkałem błąd interfejsu użytkownika z SO), ale nie mogę usunąć nagrody

— Nevir

powinieneś być w stanie usunąć nagrodę

— Akshay Giri FR

138

Odpowiedź phpguy jest poprawna, ale myślę, że istnieje wiele nieporozumień w dodatkowych szczegółach.

Podstawowa odpowiedź znajduje się w BLOBdomenie typu / atrybutu danych. BLOB jest skrótem od Binary Large Object, a ten typ danych kolumny jest specyficzny dla obsługi danych binarnych.

Zobacz odpowiednią stronę podręcznika MySQL .

— Mata
źródło

57

W przypadku tabeli takiej jak ta:

CREATE TABLE binary_data (
    id INT(4) NOT NULL AUTO_INCREMENT PRIMARY KEY,
    description CHAR(50),
    bin_data LONGBLOB,
    filename CHAR(50),
    filesize CHAR(50),
    filetype CHAR(50)
);

Oto przykład PHP:

<?php
    // store.php3 - by Florian Dittmer <dittmer@gmx.net>
    // Example php script to demonstrate the storing of binary files into
    // an sql database. More information can be found at http://www.phpbuilder.com/
?>

<html>
    <head><title>Store binary data into SQL Database</title></head>

    <body>
        <?php
            // Code that will be executed if the form has been submitted:

            if ($submit) {
                // Connect to the database (you may have to adjust
                // the hostname, username or password).

                mysql_connect("localhost", "root", "password");
                mysql_select_db("binary_data");

                $data = mysql_real_escape_string(fread(fopen($form_data, "r"), filesize($form_data)));

                $result = mysql_query("INSERT INTO binary_data (description, bin_data, filename, filesize, filetype) ".
                                    "VALUES ('$form_description', '$data', '$form_data_name', '$form_data_size', '$form_data_type')");

                $id= mysql_insert_id();
                print "<p>This file has the following Database ID: <b>$id</b>";

                mysql_close();
            } else {

                // else show the form to submit new data:
        ?>
        <form method="post" action="<?php echo $PHP_SELF; ?>" enctype="multipart/form-data">
            File Description:<br>
            <input type="text" name="form_description"  size="40">
            <input type="hidden" name="MAX_FILE_SIZE" value="1000000">
            <br>File to upload/store in database:<br>
            <input type="file" name="form_data"  size="40">
            <p><input type="submit" name="submit" value="submit">
        </form>

        <?php
            }
        ?>
    </body>
</html>

— Mauris
źródło

9

Ten kod wygląda jak PHP3 (a może 4), który włącza register_globals. Nie chcesz uruchamiać tego kodu i nie będzie on również działał na częściowo aktualnej instalacji PHP (która jest w wersji 5).

— Do

26

-1 dla addlashes (), gdzie potrzebna jest mysql_real_escape_string (). Czy możemy przestać udostępniać ludziom kod z lukami w iniekcji SQL? (Nie, sumy dodatkowe () NIE są wystarczająco dobre.)

— chaos

40

Gorąco polecam na przechowywanie danych binarnych w relacyjnej bazie danych. Relacyjne bazy danych są zaprojektowane do pracy z danymi o stałym rozmiarze; na tym polega ich siła wydajności: pamiętasz stary artykuł Joela, dlaczego bazy danych są tak szybkie? ponieważ przejście z rekordu do innego rekordu wymaga dokładnie 1 przyrostu wskaźnika. Jeśli dodasz dane BLOB o nieokreślonym i bardzo zróżnicowanym rozmiarze, obniżysz wydajność.

Zamiast tego przechowuj pliki w systemie plików i przechowuj nazwy plików w bazie danych.

— Alex Weinstein
źródło

11

Nie głosowałem za tym, ale może to wynikać z sugestii, że NIGDY nie powinieneś tego robić, w przeciwieństwie do tego, że przez większość czasu jest to zły pomysł. Zgadzam się z nim ogólnie, ale nie w 100% przypadków. Mogą istnieć inne czynniki niż wydajność. Na przykład pracuję teraz nad czymś, w którym wydajność nie ma żadnego znaczenia. Inne czynniki, takie jak centralizacja, prostota i kopie zapasowe oznaczają, że w tym przypadku przechowywanie w bazie danych ma sens. Innym częstym powodem jest replikacja.

— LaVache

4

Z drugiej strony przechowywanie danych w db jest niezależne od systemu operacyjnego, co może być przydatne w przypadku dziwnych nazw plików. db może przechowywać wiele plików o tej samej nazwie, system operacyjny nie może. Nie ma problemów z odczytem / zapisem / usuwaniem. Nie wymaga dodatkowego systemu tworzenia kopii zapasowych. I to nie jest publiczne. Czasami więc rozwija się szybko. Btw. nikt nie zmusza cię do przechowywania wszystkiego w tej samej bazie danych, ostatecznie wszystko kończy się na dysku.

— Joeri

7

@AlexWeinstein, mylisz dane binarne z danymi o stałej szerokości. Dane binarne mogą również mieć stałą szerokość. Dane o stałej szerokości nie są odpowiednie dla wszystkich sytuacji. Rzeczywiście, w wielu sytuacjach skorzystasz z danych o zmiennej szerokości: przeczytaj ostatni akapit dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html

— Pacerier

4

Zgadzam się z @Pacerier w tej sprawie, BINARY (16) jest przechowywany na stałe. Jeśli chodzi o BLOB: BLOB ma wskaźnik o stałej szerokości do danych przechowywanych poza tabelą. W przeciwieństwie do varchar lub varbinary, które przechowują go w linii. Przeszukiwanie obiektu blob wymaga kilku dodatkowych kroków, ale pomiń klauzulę WHERE i jest w porządku.

— Garr Godfrey,

4

myślę też, że przechowywanie plików w systemie plików jest bardzo zepsute i nieprzenośne. co jeśli plik zostanie usunięty?

— Garr Godfrey,

22

Chociaż nie powiedziałeś, co przechowujesz, i możesz mieć z tego dobry powód, często odpowiedź brzmi „jako odniesienie do systemu plików”, a rzeczywiste dane są gdzieś w systemie plików.

http://www.onlamp.com/pub/a/onlamp/2002/07/11/MySQLtips.html

— Issac Kelly
źródło

17

To zależy od danych, które chcesz przechowywać. W powyższym przykładzie użyto LONGBLOBtypu danych, ale należy pamiętać, że istnieją inne formaty danych binarnych:

TINYBLOB/BLOB/MEDIUMBLOB/LONGBLOB
VARBINARY
BINARY

Każdy ma swoje przypadki użycia. Jeśli jest to znana (krótka) długość (np. Spakowane dane) często razy BINARYlub VARBINARYzadziała. Mają dodatkową zaletę, że są w stanie indeksować ton.

— d0nut
źródło

14

Chociaż nie powinno to być konieczne, możesz spróbować base64zakodować dane i je zdekodować. Oznacza to, że db będzie mieć tylko znaki ascii. Zajmie to trochę więcej miejsca i czasu, ale wszelkie problemy związane z danymi binarnymi zostaną wyeliminowane.

— użytkownik10117
źródło

11

Jeśli istnieje pole - nie zalecane - BLOB, możesz zapisać dane w ten sposób:

mysql_query("UPDATE table SET field=X'".bin2hex($bin_data)."' WHERE id=$id");

Pomysł zaczerpnięty stąd .

— Społeczność
źródło

10

Powstaje również pytanie, jak wprowadzić dane do BLOBA. Możesz umieścić dane w instrukcji INSERT, jak pokazuje przykład PHP (chociaż powinieneś użyć mysql_real_escape_string zamiast dodawania). Jeśli plik istnieje na serwerze bazy danych, możesz także użyć LOAD_FILE MySQL

— Scott Noyes
źródło

Ten link mówi, że MySQL_real_escape_string jest przestarzały.

— Poul Bak

10

Kiedy muszę przechowywać dane binarne, zawsze używam VARBINARYformatu, zgodnie z wprowadzeniem byd0nut.

Dokumentację można znaleźć na stronie MySQL w udokumentowanym temacie 12.4.2 Typy BINARY i VARBINARY

Jeśli pytasz, jakie są zalety, spójrz na pytanie dlaczego-varbinary-zamiast-varchar

— zeppaman
źródło