Артём Каретников

Зачем Primary key стоит на обоих полях? В таблице Users не нужно это, обычный int и все.

Если будут связи между этими таблицами - например, информация на табло и техобслуживание связаны как-то, то я бы делал в одной. Если нет - в разных, потому что это изначально разные бизнес-процессы.
В общем случае - зависит от объема работ. Если небольшое количество таблиц, то все в одной, если много - в разных. Просто исходя из удобства разработки.

vb6 еще живой? :)

По памяти:
Dim NextP As NPackets
...
For Each Link In NLinks
set NextP = New Npackets
...

e1s: через ## - тогда будет видна другим. Однако использование временных таблиц такого рода часто говорит о том, что ее просто надо сделать постоянной. Надо понимать, что создание и удаление таблиц - ресурсоемкое дело и лучше бы их не использовать, кроме тех мест, где это реально необходимо.
Зачастую временную таблицу можно заменить запросом типа select myfield from (select id_table from mytable) либо используя cte - последний способ весьма хорош, если подобная "временная таблица" будет использоваться в процедуре часто.

Не стоит так же забывать про индексы на временные таблицы.

Конечно, он недоступен, потому что в обоих случаях первичный ключ. Зачем в таблице Общая - такой сложный составной первичный ключ? Зачем в ней же тип оборудования уже есть - но еще и ссылка на таблицу типа оборудования?
Как минимум это - лишнее. У вас в таблице "общая" поле Код_ТО должно быть не первичным ключем. Поле "тип оборудования" - вообще к аллаху, его не нужно, потому что на него будет ссылка.

В таблице "тип оборудования" - поле тип оборудования - тоже не должно быть первичным ключем. А вот Код_ТО - это первичный ключ однозначно. И вот его берете мышой и швыряете на таблицу "Общая" - тогда у вас как раз создастся тип "один ко многим".
Сама схема данных... Оставляет желать, конечно, лучшего. Почему в "выезде" - код_ремонтника - не первичный ключ, а ремонтник, т.е. текстовое поле с фамилией именем, первичный? Должно быть с точностью до наоборот.
Зачем в депо код депо - не первичный ключ, а первичным ключем сделаны Название_Депо и Код_ВРК? И так далее.

Процедура? :)

Конечно. Не делать это в цикле, а делать пакетно. Кстати, хорошо бы код показывать и объяснять, зачем такой цикл необходим.

Доброго.

Конечно, первый вариант. Остальные можно рассматривать только если уж хочется ну идеальнейшей оптимизации, но.

1. Эти поля у вас наверняка в запросах участвовать не будут, ни индексов, ни оптимизации им просто не нужно.
2. На выборку данных из них, если она все же потребуется, например, для создания описания базы, нужны будут запросы похитрей. На их создание и на реализацию всего, кроме первого варианта - потребуется время, которое лучше пустить на разработку базы
3. Все эти хитрые запросы не будут восприняты ни одной системой автоматической генерации описаний.
4. Вряд ли описания настолько часто совпадают и их настоль много, что оптимизация их ускорит выборку.

В общем, овчинка выделки не стоит, коллега.

Не бывает чудес, Золушка. А это именно чудо, а скорее - невнимательность. Скопирована, например, не база, а линк на нее. Или при открытии базы данных выбираете одну, а полагаете, что другую.

Хотя есть еще один вариант, вполне вероятный. Если есть третья база, в которой собственно хранятся значения и она прилинкована как источник данных. Скриншот с окна с таблицами нужен, там это сразу видно.

А реализация на макросах, с вероятностью в 99 процентов. У майкрософта по умолчанию макросы отключены и им не доверяют. Варианта два - сделать файл доверенным, открыв его через офис, и - правильный, заменить макросы на программный код и не использовать.

Я бы развел в два разных поля, если уж желается максимальной производительности. Тогда понять, сколько за, сколько против - простой суммой можно будет, да. Но если со всей прямотой - можно и в одном поле типа инт хранить оба типа, пренебрежимо мала будет разница. Хранить сумму не надо, ее дешевле посчитать. За: 1, против -1, нормально.
А вот дальше - ну, как минимум пригодится айпишник, чтобы одному не давать голосовать несколько раз, да? Еще одно поле.
Если есть необходимость хранить данные их соцсетей, а сейчас модно хранить вообще все про юзера, то еще поле под ссылку на соцсеть и второе - на тип этой сети. Итого:

rid (Pkey), u_vote, u_ip, u_soc_net, u_soc_net_type.

Индекс только на поле u_vote в рамках данной задачи. Если нужна будет выборка по соц.сетям - то индекс на тип соцсети.

Повредиться база акцесса может отчего угодно, увы. Бекапить надо.
Помочь может следующее:
1. Создаете новую базу акцесса.
2. Правой кнопкой или в меню импорта - импортировать таблицы.
3. Указываете путь к этой вашей поврежденной базе.

Если сам акцессс что-то найдет - то покажет, что найдено.

Express версия имеет ограничения все же, а вот MS SQL Developer Edition нынче стала бесплатной, с 2014 версии. Абсолютно все возможности Enterprise версии в ней есть.

Для начала - возможностей самой студии более чем достаточно. Если не складывается с ней - неплохие программы для работы с базами данных, в русских версиях бесплатные, делает devart.com

То, что голова идет кругом - вернейший признак того, что нет бизнес-требований. В идеале, за такую базу не нужно браться вообще - это прямой путь к увольнению. "Вот нам надо было, а Павел сделал все не так, а нам надо было так!"

Ну и попытка объять необъятное тут. Мега-учет в одно лицо? Не надейтесь справиться, никто это в одиночку не делает. Вот это все "количество сотрудников в комнате", "количество лифтов" - крайне сомнительно, что это вообще нужная информация.

Мои рекомендации: сесть и спокойно подумать о чем-то другом. Пару дней. Понять реальные требования в их минимальном масштабе. Конкретизировать их. Не спешите думать о структуре.

Нужен учет сотрудников в организации - это уже отдельная база данных. Нужен учет материальных средства - это еще одна отдельная база данных. И так далее.
И заметьте - на рынке есть решения этих вопросов, но нет монополиста и есть масса самописных решений. Это о чем говорит? Еще раз о том, что универсального решения нет, но есть методы для _конкретных_ задач.

Я бы не стал на вашем месте удалять из таблицы ничего. А просто создал бы новую, уже без дублей. В плане потребления ресурсов - оно значительно экономней будет. И никто не мешает сделать так:
1. Первые сто тысяч отобрал, запомнить id последней записи.
2 .Пауза.
3. Отобрал следующие сто тысяч начиная с последнего айди. Гоу ту пункт два.

Все.

Запихните результат во временную таблицу и сделайте выборку из нее. Где уже не надо будет выполнять concat.