Ya kamu bisa!! Solusinya harus mudah, aman, dan efektif ...
Saya baru mengenal postgresql, tetapi tampaknya Anda dapat membuat kolom yang dihitung dengan menggunakan indeks ekspresi , dipasangkan dengan tampilan (tampilan bersifat opsional, tetapi membuat hidup sedikit lebih mudah).
Misalkan perhitungan saya md5(some_string_field)
, maka saya membuat index sebagai:
CREATE INDEX some_string_field_md5_index ON some_table(MD5(some_string_field));
Sekarang, kueri apa pun yang bekerja MD5(some_string_field)
akan menggunakan indeks daripada menghitungnya dari awal. Sebagai contoh:
SELECT MAX(some_field) FROM some_table GROUP BY MD5(some_string_field);
Anda dapat memeriksa ini dengan menjelaskan .
Namun pada titik ini Anda mengandalkan pengguna tabel yang tahu persis bagaimana membuat kolom. Untuk membuat hidup lebih mudah, Anda dapat membuat VIEW
tabel asli ke versi augmented, menambahkan nilai yang dihitung sebagai kolom baru:
CREATE VIEW some_table_augmented AS
SELECT *, MD5(some_string_field) as some_string_field_md5 from some_table;
Sekarang kueri apa pun yang digunakan some_table_augmented
akan dapat digunakan some_string_field_md5
tanpa mengkhawatirkan cara kerjanya .. mereka hanya mendapatkan kinerja yang baik. Tampilan tidak menyalin data apa pun dari tabel asli, jadi ini adalah memori yang baik dan juga kinerja. Namun perlu dicatat bahwa Anda tidak dapat memperbarui / menyisipkan ke dalam tampilan, hanya ke dalam tabel sumber, tetapi jika Anda benar-benar menginginkannya, saya yakin Anda dapat mengarahkan penyisipan dan pembaruan ke tabel sumber menggunakan aturan (saya bisa saja salah pada poin terakhir sebagai Saya belum pernah mencobanya sendiri).
Sunting: tampaknya jika kueri melibatkan indeks yang bersaing, mesin perencana terkadang tidak menggunakan indeks ekspresi sama sekali. Pilihannya tampaknya bergantung pada data.