Максим Федоров

UPDATE `tablename` SET `vtc` = REPLACE(`vtc`, ' ', '')

Если правильно понял принцип работы тогда речь идет о паттерне Class Table Inheritance описанной Фаулером

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

1. Null обозначает отсутствие значения. Если у Вас есть столбец который по логике не может быть без значения, но при этом в него можно записать null - это свидетельство плохого дизайна Вашей базы
2. Null-cтобцы как правило жрут дополнительные ресурсы, из за чего скорость обработки данных в базе может уменьшиться. На маленьких объемах Вы этого не заметите, но если будете работать с большой высоко нагруженной базой скорость будет играть огромное значение

Сохранение идентификаторов в виде строке крайне плохая практика. Просто сохраняйте данные в формате

FruitsID        tagID
1               1
2               1
2               2

Что лучше дальше пытаться подобрать оптимальные варианты составных индексов,

Здесь нужно знать меру, не стоит забывать - чем больше индексов тем больше будет места на сервере занимать база и тем медленнее будет производиться запись данных.

или сделать один составной индекс сразу на 10 полей от А до G например?

в этом случае индекс не будет использоваться, читайте как устроены индексы в MySQL ruhighload.com/post/%D0%A0%D0%B0%D0%B1%D0%BE%D1%82...

вообще рекомендовал бы Вам посмотреть в сторону поисковых движков...

Даты на скрине храняться в UNIXTIME, поэтому что бы получить из даты год Вам нужно ее конвертировать, например так:

SELECT YEAR(FROM_UNIXTIME(`year`)) as y FROM tablename

Хранить такие данные в сериализованом массиве вообще не тру. Для таких задач либо создаются три таблицы:
- Товары
- Характеристики
- Значение характеристики для товаров
либо используются NoSQL базы данных. А выбор из этих подходов стоит делать исходя из требований и нагрузок Вашей системы.

что-то типа такого

CREATE TRIGGER `edit_record` 
BEFORE UPDATE ON `tablename` 
FOR EACH ROW SET new.updateTime = CURRENT_TIMESTAMP();

в BETWEEN первой число это начала диапазона, а второе окончание.
Ваш запрос
`user` BETWEEN 1000 AND 100
аналогичен такому:
`user`>=1000 AND `user`<=100
как видно из такого условия 500 не больше 1000 и не меньше 100, т.е. нужно формировать запрос так:
`user` BETWEEN 100 AND 1000

decimal(5,2) где 5 - количество знаков в числе, 2 - кол-во знаков после запятой

ошибка возникает в следствии попытки добавить данные с одинаковыми Primary Key. Используйте UPSERT если это позволяет Ваша версия постгреса, если не позволяет - в интернете полной информации как реализовать самому его аналог в более старых версиях.