Действительно ли хорошо сохранить длинные строки в базе данных?
- 1-й создают экземпляр эти
PrintDialogобъект. - затем звонят, диалоговое окно печати возражают и уезжают эти
PrinterNameпробел. это вызовет объект окон возвратить defualt название принтера - запись это к строке и использовать его в качестве названия принтера при вызове Кода процедуры
печати:
Try
Dim _printDialog As New System.Windows.Forms.PrintDialog
xPrinterName = _printDialog.PrinterSettings.PrinterName '= "set as Default printer"
Catch ex As Exception
System.Windows.Forms.MessageBox.Show("could not printed Label.", "Print Error", MessageBoxButtons.OK, MessageBoxIcon.Error)
End Try
8 ответов
Сохранение строки в базе данных должно быть нормальным. Если вместо этого вы храните файловый указатель, это означает, что вам нужно выполнять файловый ввод-вывод каждый раз, когда вы хотите прочитать строку. Несколько предложений не очень длинные, и вы всегда можете использовать поле данных с длинным текстом, если вам нужно. Очевидно, ваша база данных будет немного больше, потому что у вас есть текст, но это нормально. Это, безусловно, лучшая альтернатива, чем хранить файлы.
Строки, которые вы упомянули, совсем не длинные.
Когда вы говорили о «длинных» строках, я думал о 32 КБ и выше - некоторые предложения имеют размер <1 КБ, то есть сегодня ничего.
Ваш трюк с сохранением идентификатора замедляет работу, так как вам приходится выполнять косвенный доступ.
Единственное, что я бы порекомендовал, когда требуется максимальная производительность, вы должны выбирать только те столбцы, которые вам нужны (опустить SELECT *) - опускайте текстовый столбец, когда он не нужен, поскольку транспортировка строки от сервера к приложению требует больше всего времени. Это хорошая практика - не трогать ненужные столбцы (особенно если они могут содержать много данных).
Единственная причина, по которой я хотел бы создать отдельную таблицу, - это если эти длинные строки будут одинаковыми для многих записей. В противном случае это просто дополнительное осложнение, которое вряд ли окупится.
Пять-шесть предложений - это пустяк для современной СУБД! Сохраните текст непосредственно в базе данных.
(Другой упомянутый вами метод - сохранение ссылки на другую таблицу, которая сама имеет ссылку на внешний файл, содержащий текст - было бы гораздо более громоздким в использовании и с гораздо меньшей производительностью. )
Ответ действительно зависит от объема строк, которые вы собираетесь хранить, и от того, какую БД вы собираетесь использовать для их хранения. Если вы не храните много строк, вы можете подумать о том, чтобы сохранить их в XML или файле ресурсов и загрузить их в свое приложение заранее. Однако, если у вас много строковых данных, вам, вероятно, будет лучше читать строку по памяти по мере необходимости, чем рисковать считывать строку в память, которую вы в конечном итоге не используете.
За исключением особых случаев, я бы оставил поле там, где оно есть.
Единственный другой вариант - поместить строки в другую таблицу (поместив туда фактические строки). .. размещение их в отдельных файлах убьет вашу производительность.
Все упоминали производительность, но никто не упомянул другую важную причину, по которой хранение указателей в файлы ОС - плохая идея: резервное копирование и восстановление. Если все находится в базе данных, то у нас есть единый механизм резервного копирования данных и единый механизм восстановления. В то время как с файлами в ОС у нас есть два разных механизма резервного копирования, вероятно, с двумя разными уровнями детализации, и восстановление становится кошмаром синхронизации.
Есть несколько случаев, когда это не применимо, например, хранилища данных, которые используются очень редко. транзакции и поэтому могут выжить без повторного выполнения или журналов транзакций.
Сама база данных не имеет серьезных проблем с хранением длинных строк. Применяются некоторые ограничения (например, ограничение на размер записи 8 КБ на SQL Server), но даже в этом случае вы можете хранить текст произвольной длины в базе данных, потому что все подходящие поддерживают типы данных BLOB / TEXT практически без верхнего предела.
От пяти до шесть предложений - это не очень долго. Если они принадлежат друг другу и предназначены для извлечения и манипулирования как целое, вы можете продолжить и сохранить их в поле типа данных CHAR соответствующих размеров.
Возникает только вопрос о том, разделять ли их и прикреплять к ним идентификатор. если ваше приложение / модель данных напрямую выигрывает от этого подхода, т.е. на самом деле это разные вещи. В вашем случае, похоже, нет причин идти по этому пути.