На K.I.S.S и мощение коров

В настоящее время я разрабатываю приложение PHP, использующее базу данных Access как бэкэнд. Не по выбору вы понимаете... база данных - это то, что клиент использовал изначально, а использование этого - часть требований. Одна из проблем с этой базой данных состоит в том, что имена столбцов имеют самое сумасшедшее соглашение об именах, которое вы могли бы себе представить. Верхний, строчный, подчеркивающий, пробелы и просто безумный. Например, столбец "пол" содержит дату. И столбец "User2". Там гораздо больше, но вы получаете идею. Столкнувшись с этим, я решил создать массив для сопоставления столбцов базы данных с переменными PHP, чтобы мы могли изолировать код от безумия. Однако мой коллега полагает, что я слишком усложняю ситуацию, и мы должны использовать имена столбцов базы данных для соответствующих переменных PHP, поэтому нам не нужно проходить через массив сопоставлений, чтобы найти, что там происходит. Итак, мой вопрос в том, что... я поступаю правильно или я усложняю вещи?

14 ответов

Абсолютно ты на правильном пути. Если вы не отвлечете безумие, вы в конце концов поддадетеся безумию.

У вашего коллеги есть действительная точка, поэтому я предлагаю вам также прописать простой способ определить данные для сопоставления столбцов в PHP.

Речь идет не о том, чтобы это было просто, а о том, как дооснастить прочную основу.

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


Имена исключительно важны. Если вы хотите, чтобы ваше приложение поддерживалось, исправьте их до того, как база кода будет расти дальше.


Я бы не сказал, что вы усложняете вещи.

Книга Эрика Эвана Domain Driven Design имеет прекрасный термин для этого: Уровень защиты от коррупции


Чтобы играть в Devil Advocate, нужно что-то сказать, чтобы не иметь ненужного слоя косвенности в вашей кратковременной загрузке памяти для работы с системой. Узнав код, вы узнаете, что входит в эту переменную, поэтому основным преимуществом является то, что кто-то новый собирает код с нуля. Однако исправление этой проблемы также потребовало бы исправления схемы базы данных, которая (а) была бы значительной частью работы, и (б) в значительной степени устраняет проблему.

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

С другой стороны, если операция очистки находится в пределах возможностей, то вы можете захотеть сделать это на основе типа повторного факторинга, поэтапно фиксируя имена столбцов БД в качестве возможности.


Просто создайте представления, где это наиболее необходимо.


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

Ваша точка коллеги не должна перегружать вещи. Это действительно тоже.

Итак, инкапсулируйте доступ к полям в методе или методах и попросите этот метод выполнить перевод. Используя карты, это не должно быть проблемой производительности.

Фактически размещение всего сопоставления источнику данных в одном объекте может помочь вам, если ваш клиент пересматривает использование реальной базы данных. И клиенты любят менять свое мнение.


Почему бы не создать datalayer с классами, которые отображаются на каждой таблице. Затем вы можете определить методы класса для доступа к столбцам и дать методам любые имена, которые вы хотите. Тогда код доступа к базе данных datalayer - это единственное, что нужно знать о именах реальных столбцов. Я подозреваю, что кто-то (возможно, несколько сонеонов) уже разработал рамки для этого. Google "php orm".


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

Я бы, возможно, создал структуру данных, содержащую имя базы данных, дезинформированное имя, тип и поле для содержимого, когда вы вытаскиваете данные из БД. Это дало бы удобный способ рисовать вещи, чтобы вы не только отбрасывали сумасшедшую схему имен.


Вы не сказали, что не можете переименовать столбцы в Access, так что... сделайте это! Другая возможность - создать представления для каждой таблицы и переименовать столбцы в представлении. Затем вместо работы с Table Employees вы работаете с видом vEmployees. Если я правильно помню, Access позволяет вам обновлять представления, а также выбирать из них. Если вы используете ORM с PHP, это может не поддерживать обновление просмотров.


Это хороший вопрос, поскольку он говорит о сердце кодирования ИМХО.

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


Имена таблиц жестких кодировок и имена столбцов никогда не являются хорошей идеей, даже если имена имеют смысл.

Я не знаю, является ли использование массивов лучшим решением. Я не очень хорошо знаком с PHP, но я бы пошел с чем-то вроде постоянных строк для хранения имен таблиц. На языках, с которыми я работаю, это приведет к появлению более читаемого кода.


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

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

Конечно, я бы все же сказал, что KISS относится к методу вашего отображения!


Используйте ORM, вы скоро меняете db...


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

licensed under cc by-sa 3.0 with attribution.