Драйверы на bluetooth установлены из родного инсталлятора для вашей модели ноутбука? Не из драйверпака на все случаи жизни и не из поисковиков по devid?
Таблица в СУБД, и то что вы представляете в качестве таблицы (сущности) на уровне бизнес-логики приложения - это разные вещи. Сущность на уровне бизнес-логики не будет один в один укладываться в такую же единицу в терминах СУБД. Таблицы в СУБД используют реляционный подход, который не соотносится с сущностным подходом. Этот разрыв требует от разработчика определенного навыка анализа предметной области, чтобы преобразовывать сущности в отдельные таблицы (так называемый процесс нормализации данных). Вам нужно с одной стороны понять, как работает реляционная алгебра в СУБД, как правильно создаются объекты в ней (таблица - это только один из объектов, есть еще связи, триггеры, последовательности, представления и т.д.) и как их правильно используют. А с другой стороны, нужно научиться анализу предметной области, выделять сущности, классифицировать их, видеть какие вспомогательные сущности должны быть созданы, как их перенести на объекты СУБД (не только таблицы). Это в купе довольно сложно объяснить в одном комментарии, но между СУБД и приложением есть определенная пропасть, и навыки программиста как раз направлены, чтобы пробросить мост над ней.
Загружаете контент в объект DOMDocument. Далее, подбираете правило DOMXPath, чтобы выцепить нужный html узел. Ну, а дальше получаете содержимое этого узла.
Хранить бинарные данные (произвольные файлы) в базе данных - не самый оптимальный выход.
Для хранения файлов нужно стремиться создавать отдельный сервис с управлением доступа к нему.
Так как СУБД может иметь отличный график создания резервных копий (может быть более частым или вообще в режиме репликации работать), то наличие бинарных данных может дать сильный прирост в размере резервных копий.
Вторая проблема - некоторые запросы могут лишиться возможности получать агрегированные выборки по произвольным полям - это нужно будет проследить при введении бинарных полей в таблицы, чтобы не упали приложения.
Но тем не менее, в некоторых кейсах можно рассмотреть вариант хранения в базе файлов.
Для этого должны быть следующие предпосылки:
- загрузка файлов, предназначенные для сохранения в базе, не загружаются рядовыми пользователями;
- пользователь, которому доверена загрузка файлов, всегда склонен выбирать файлы для сохранения с оптимальным размером и качеством (даже может быть прописан регламент);
- кол-во файлов для одного информационного объекта не может быть неограниченным числом;
- нужно обеспечить максимально простой доступ к файлам в различных системах, причем, уровень прав доступа совпадает с ролями пользователей в СУБД.
Конкретный пример.
Хранение фото для пропуска работников предприятия. Загружает файл только работник отдела кадра. Параметры файла регламентированы. Доступ к файлу имеет софт отдела кадров и софт на компьютере охраны на проходной.
Сдается мне, что между компом и выходом в интернет должно оставаться включенным устройство с не тривиальным функционалом (мини-сервер). Например, роутер, прошивка которого позволяет устанавливать дополнительные утилиты. Чтобы висеть на сером IP адресе и быть доступным извне, нужен функционал dynamic DNS. А чтобы что-то передать внутрь локальной сети, то, скорее всего, нужен функционал reverse proxy. Получается, что перед уснувшим компом должен быть какой-никакой мини-комп или роутер с открытыми возможностями замены ПО.
А разве событие onload на img не зависит от источника данных в src? Насколько помню, как только img получает корректные данные картинки, он сразу поджигает это событие, а в этом обработчике уже все размеры получить можно.
1) Выключить лого.
2) Посмотри внимательно на сообщения в первые несколько секунд до загрузки ОС (можно использовать кнопку pause).
Если задержка на проверке устройств sata - то мешают диски.
Если пишет, что-то типа настройки биоса испорчены, загрузка настройки по умолчанию. То зайти в биос и вызови сохранение настройки. Еще можно проверить батарейку биоса мультиметром, чтобы было 3 вольта.
3) Включить фаст бут.
А какие мероприятия по оптимизации вы проводили?
Анализировали план выполнения запросов?
Оптимально ли составлены сами тексты запросов (или все скрыто под покровами ORM)?
Все ли индексы отвечают потребностям выборки данных?
А не забыли ли про связи между таблицами, или они только на уровне софта подразумеваются?
Нет ли очередей мелких запросов там, где можно сделать один запрос, но на всю выборку?
300 тыс записей - это детский размер для реляционной базы.
Самое легкое, во что можно переделать блок select - это в радиокнопки. Вы беретесь за те задания, теоретическую основу которую не понимаете (базовые элементы формы и как они превращаются в GET или POST параметры при submit).
order by isphoto desc
Были проблемы определить приоритет сортировки при наличии других сортируемых полей?