Lynn «Кофеман», это server side среды. Если не уточнять какая среда по мотивам синтаксиса JS используется, или каким интерпретатором оно реализуется, то создается впечатление, что хотят классический вариант JavaScript.
Вы все таки десктопное приложение разрабатываете, или хотите, чтобы ваше приложение портировалось в среду браузера? Причем здесь JS (он же Javascript, который в браузере работает)?
Это отдельный вид объектов в СУБД, даже память под них выделяется существенная, когда они работают. Учите базу не по интерфейсу phpmyadmin, а по документации.
PK - это первичный ключ, позволяет однозначно идентифицировать запись в таблице, сам по себе несет ограничение уникальности, и на это поле можно ссылаться из других таблиц (там эта ссылка называется внешним ключом).
UQ - уникальность поля, выставляет ограничение на колонку, при которой вставка одинакового значения невозможна.
AI - автоинкремент поля. Позволяет автоматически вставлять новое значение поля (+1 от ранее вставленного) при вставке, не упоминая названия поля в операторе insert. Это нестандартный для классического SQL объект, обычно, в других СУБД используют триггер+последовательность (AI в MySQL - это как раз 2 в 1).
Но PK, UQ, AI - это не то, что нужно для индексов.
Тебе нужно создать на каждое поле по индексу, без флагов UQ - выставлять уникальность поля не нужно, иначе ты не вставишь новую запись с одинаковым значением этого поля.
На БП есть таблица токов по разным линиям.
Тебе нужно смотреть +12В сколько ампер там (может даже ватты написаны). 12*амперы = получишь макс. ватты на линию 12 вольт. Отними от этого макс. TDP процессора - примерно получишь запас для видеокарты, но это не точно.
Тогда уточните, какой датчик температуры вы смотрели в AIDA64 (процессора, одного ядра процессора, видеокарты, материнской платы - как минимум столько там разных температур). А вот в MS Afterburner вы видели температуру видеочипа.
И при каких обстоятельствах - нагружали тестирование или нет, запускали игру и т.д.
Я думаю, если эти два пункта проясните, то вопрос отпадет сам собой.
Надеюсь этот id - не первичный ключ таблицы клиентов.
Если у вас штатно есть действие на смену именно первичного ключа, то это не есть хорошо, что-то в на этапе проектирования базы не учли.
Нужно больше сведений о структуре таблиц, где у вас имеются идентификаторы клиентов и что из них повторяется/меняется.
1. Печать листов.
2. Сшивание листов в тетради, тетради в блок.
3. Обрезка блока.
4. Печать обложки/приобретение обложки со стандартным рисунком.
5. Сборка книги.
Любой из этих этапов вы можете сделать сами или поручить фирме. От этого будут зависеть издержки.
Кто пишет свои фанфики и хотят видеть свой материал на бумаге в виде книги вот этим и занимаются.
Если у вас остался нетронутый экземпляр программы, через который вы заходили раньше, то можно попробовать выдернуть оттуда дополнительную информацию - найти email к которому была привязана учетка.
Skype, который устанавливается отдельным exe файлом, не из приложения Microsoft Store, в каталоге Пользователя, создает каталог для временных файлов:
C:\Users\<Ваш Пользователь>\AppData\Roaming\Skype
Среди них есть файл локальной базы данных database.db (или другой db файл), в который он кеширует состояние профиля.
Этот файл можно открыть любым редактором для баз SQL lite и посмотреть, что там в табличках находится.
Сообщения там точно были, возможно, какие-то данные профиля туда тоже кешируются. Можно попробовать узнать о своем профиле чуть побольше.
Но это сработает, если вы не удаляли Скайп, и его запчасти остались нетронутыми после последующих обновлений (не знаю, сейчас они используют локальную базу данных для кеша, или уже прикрыли лавочку в угоду приватности).
CTE и window function есть почти во всех нелокальных СУБД, и в русских источниках они описаны как общие табличные выражения и оконные функции.
У вас как раз задачка самая показательная под демонстрацию возможностей этих методов.
Хорошая идея. За одно беспроводной колонкой еще можно гальванически развязать аудиосистему и источник звука. Если при эксперименте что-то пострадает, то ограничится это схемой колонки.
Тогда вам дорога в plpgsql.
Конструируйте динамически запрос в виде строки этим процедурным языком, выполняйте его и выгружайте результат во временную таблицу. Из этой таблицы заберете приемлемый результат. Но этот путь - это попытка создать из хлеба троллейбус.
Объем данных таблицы тут ни причем, для обычного join это вообще типовая выборка.
Вы никогда не будете явно выбирать 100К.
Либо выборка будет происходить в пределах одного товара, либо в пределах страницы в 10, 50, 100 товаров.
Во всех этих случаях, если правильно создать индексы на колонках "свойства товара".id_prod и "свойства товара".id_prop, то запрос с join-инами будет всегда легковесным.